-
MedTech
Chapter 2 Requirements Specification
How to write a requirements specification
Dr. L i l ia SFAXIw w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 1
MedTech Mediterranean Institute of TechnologySoftware Engineering
MedTech
-
MedTech
Requirements Specification Why?
2
If you dont know where youre going, you will probably end
up somewhere else. Laurence J. Peter
-
MedTech
SRS: Software Requirements Specification
The organizations understanding, in writing, of a customer or potential clients system requirements and dependencies at a particular point in time, usually prior to any actual design or development work.
A two way insurance policy Insures that both the client and the organization understand the
others requirements from that perspective at a given time
States: The functions and capabilities a software system must provide The required constraints by which the system must abide
Called the parent document
3
Requirements Specification
-
MedTech
SRS: Major Goals
Providing feedback to the customer SRS is the customers assurance that the dev. organization understands his
needs SRS should be written in a natural language, in an unambiguous manner May include charts, tables, data flow diagrams, decision tables,
Decomposing the problem into component parts The information is organized, borders are placed, ideas solidified
Serving as an input to the design specification As a parent document, it comes prior to the design spec. Must then contain sufficient details about the functional systems
requirements for the design solution to be devised
Serving as a product validation check Is a lso the parent document for testing and validation strategies Is a basis for estimating costs and schedules
4
Requirements Specification
-
MedTech
SRS: Content (IEEE 830 standard)
Functionality What is the software supposed to do?
External Interfaces How does the software interact with people, the systems hardware, other
hardware, and other software?
Performance What is the speed, availability, response time, recovery time of various
software functions?
Attributes What are the portability, correctness, maintainability, security, etc .
considerations?
Design constraints imposed on an implementation Are there any required standards in effect, implementation language, polic ies
for database integrity, resource limits, operating environments, etc.?
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 5
Requirements Specification
-
MedTech
SRS: What it contains, what it doesnt
SRS provides: Function requirements Non-functional requirements
SRS doesnt provide: Design suggestions Possible solutions to technology or business issues
6
Requirements Specification
-
MedTech
What makes an SRS a GREAT SRS?
An SRS should be: (IEEE 830 standard) Correct, but also ever correcting
It must be corrected whenever you find incorrect things along the dev or design phases
Unambiguous Every requirement stated therein has only one interpretation Fix ambiguities when found, instead of spending endless time trying to avoid
them
Complete It should be all that is needed by the software designers to create the software
Consistent Within itself and to its reference documents (no contradictions)
Ranked for importance and/or stability Importance and stability (chances of change) for each requirement must be
specified
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 7
Requirements Specification
-
MedTech
What makes an SRS a GREAT SRS?
An SRS should be: (IEEE 830 standard) Verifiable
fast response and the system should never crash are tota lly forbidden statements!
Provide quantitative requirements instead of just suppositions Modifiable
Prefer a shared document to multiple copies Traceable
You should document the life of a requirement and provide bi-directionaltraceability between the associated requirements
Helps find the origin of each requirement and track the changes that were made
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 8
Requirements Specification
-
MedTech
Major Challenge: Requirements Gathering
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 9
Requirements Specification
-
MedTech
Technical Writers..
A technical writer is a professional writer who produces technicaldocumentation that helps people understand and use a product or service
Technical Writers should be involved with SRS And we mean. . to the whole specification writing phase!
Benefits They can gather efficiently the information from the customer They can better assess and plan documentation projects and meet
customer document needs
They know how to determine the questions that are of concern to the user If involved early and often in the gathering process, they can become an
information resource throughout the process, rather than an information gatherer at its end
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 10
Requirements Specification
-
MedTech
Working with Requirements.. A Lifecycle Activity!
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 11
Requirements Specification
RequirementsCapture & Definition
Analysis & Design Tools
ModelingTools
SimulationTools
CodingTools
TestingTools
Requirements Management & Traceability Tools
-
MedTech
Best Practices for Writing Better Requirements
1. Use the simplest words appropriate to state a complete requirement2. Use requirement imperatives correctly
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 12
Requirements Specification
Imperatives: words and phrases that command the presence of some feature, functionor deliverable. Listed below in decreasing order of strength.
Shall Used to dictate the provision of a functional capability.
Must or must not Most often used to establish performance requirement or constraints.
Is required to Used as an imperative in SRS statements when written in passive voice.
Are applicable Used to include, by reference, standards, or other documentation as an addition to the requirement being specified.
Responsible for Used as an imperative in SRSs that are written for systems with pre-defined architectures.
Will Used to cite things that the operational or development environment is to provide to the capability being specified. For example, The vehicle's exhaust system will power the ABC widget.
Should Not used often as an imperative in SRS statements; however, when used, the SRS statement always reads weak. Avoid using Should in your SRSs.
-
MedTech
Best Practices for Writing Better Requirements
3. Do not use weak phrases and subjective words Avoid words like: adequate, appropriate, bad, better, but not limited to,
easy, minimize
4. Use continuations carefully, they make traceability difficult Continuances: Phrases that follow an imperative and introduce the
specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point.
Example: The system shall report software status to the host interface under the following conditions: At system Initia lization When the status of an external interface has changed When a report has been requested
These are actually three requirements
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 13
Requirements Specification
-
MedTech
Best Practices for Writing Better Requirements
5. Use examples, tables, figures etc. but make sure examples and notes are clearly marked as such
6. Be consistent with names! Always call the same entity by the same name
7. If you use a TBD (to be determined) or TBR (to be resolved), have a plan. You must state who is responsible for the information, and when will it be completed
8. Make sure your requirement contains all the qualities of a good requirement (see "What makes an SRS a great SRS" above)
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 14
Requirements Specification
-
MedTech
Best Practices for Writing Better Requirements
9. Make sure that if a requirement references another document, that it does so correctly References must be listed in applicable document section and state what
part of references applies
List a ll the versions of your document and the changes it applies compared to the previous version
Use a naming convention in order to apply a unique name to every document you use, for example SRS-Proj ID-Version-Date.docx
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 15
Requirements Specification
-
MedTech
Best Practices for Writing Better Requirements
10. Make sure that acronyms are used correctly Place the acronym in the acronym list in the specification Spell out the complete phrase followed by the acronym in parenthesis the
first time it is used
The next time, you can just use the acronym
11. Overspecification leads to unfunded requirements and can add duplicate requirements Shorten the requirements as possible
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 16
Requirements Specification
-
MedTech
Best Practices for Writing Better Requirements
12. Use the requirement template Define a template document for your requirements This is the structure of a basic requirement:
[Conditions] [Subject][Action][Object][Constraint] Entities: Subject o f the requirements and Object o f the actio n Actio ns: What the subject do es, co ntains an imperative Co nditio ns: What must be in place in o rder fo r the actio n to take place Co nstraints: Qualifies the actio n, perfo rmance
Example: When signal x is received, the system shall set the signal x received bit within 2
seco nds
13. Design for asset reuse14. Finding the right combination of approaches for the development process
X-driven development
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 17
Requirements Specification
-
MedTech
But also
1. Spend time specifying and documenting well software that you plan to keep. 2. Keep documentation to a minimum when the software will only be used for a
short time or has a limited number of users. 3. Have separate individuals write the specifications (not the individual who will
wr ite the code). 4. The person to write the specification should have good communication skills. 5. Take your time with complicated requirements. Vagueness in those areas will
come back to bite you later. 6. Keep the SRS up to date as you make changes. 7. Approximately 20-25% of the project time should be allocated to requirements
definition. 8. Keep 5% of the project time for updating the requirements after the design has
begun. 9. Test the requirements document by using it as the basis for writing the test
plan.
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 18
Requirements Specification
-
MedTech
References
Dr. L i l ia SFAXI w w w.l i l iasfaxi .w ix.co m/ l i l iasfaxi
Sl id e 19
Donn Le Vie , Jr, Writing Software Specifications
Michelle Specht, Best Practices Writing Requirements for Requirements Management, https://www.youtube.com/watch?v=vAEbMzNb_nM
Robert Japenga, How to write a software requirements specification