The document discusses best practices for writing a requirements specification (SRS). It begins by explaining what an SRS is, its major goals which include providing feedback to customers, decomposing problems, and serving as input for design. It describes the typical contents of an SRS based on the IEEE 830 standard, including functionality, interfaces, performance, attributes and design constraints. It then provides tips for writing high quality requirements, such as using simple language, avoiding ambiguities, ensuring requirements are complete, consistent, ranked by importance and verifiable. The document concludes with additional best practices like using templates and examples, maintaining consistency in naming, addressing references correctly, and designing for reuse.

1. MedTech
Chapter 2 – RequirementsSpecification
How to write a requirements specification
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
MedTech – Mediterranean Institute of Technology
Software Engineering
MedTech

2. MedTech
Requirements Specification… Why?
2
If you don’t know where you’re
going, you will probably end
up somewhere else.
Laurence J. Peter

3. MedTech
SRS: Software Requirements Specification
• The organization’s understanding, in writing, of a customer or
potential client’s 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
other’s 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

4. MedTech
SRS: Major Goals
• Providing feedback to the customer
• SRS is the customer’s 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 system’s
requirements for the design solution to be devised
• Serving as a product validation check
• Is also the parent document for testing and validation strategies
• Is a basis for estimating costs and schedules
4
Requirements Specification

5. MedTech
SRS: Content (IEEE 830 standard)
• Functionality
• What is the software supposed to do?
• External Interfaces
• How does the software interact with people, the system’s 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, policies
for database integrity, resource limits, operating environments, etc.?
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 5
Requirements Specification

6. MedTech
SRS: What it contains, what it doesn’t
• SRS provides:
• Function requirements
• Non-functional requirements
• SRS doesn’t provide:
• Design suggestions
• Possible solutions to technology or business issues
6
Requirements Specification

7. 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. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 7
Requirements Specification

8. 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 totally 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-directional
traceability between the associated requirements
• Helps find the origin of each requirement and track the changes that were made
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 8
Requirements Specification

9. MedTech
Major Challenge: Requirements Gathering
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 9
Requirements Specification

10. MedTech
Technical Writers..
• A technical writer is a professional writer who produces technical
documentation 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. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 10
Requirements Specification

11. MedTech
Working with Requirements.. A Lifecycle Activity!
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 11
Requirements Specification
Requirements
Capture&
Definition
Analysis &
Design
Tools
Modeling
Tools
Simulation
Tools
Coding
Tools
Testing
Tools
RequirementsManagement & Traceability Tools

12. MedTech
Best Practices for Writing Better Requirements
1. Use the simplest words appropriate to state a complete requirement
2. Use requirement imperatives correctly
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 12
Requirements Specification
Imperatives:words and phrases that command the presence of some feature, function
or deliverable. Listed below in decreasing order ofstrength.
Shall Used todictate theprovision of afunctional capability.
Must or must not Most often used to establish performancerequirementor constraints.
Is required to Used asan imperativein SRS statements when written in passivevoice.
Areapplicable Used toinclude, byreference, standards, or other documentation asan addition to the
requirementbeing specified.
Responsible for Used asan imperativein SRSs thatarewritten for systems with pre-defined architectures.
Will Used tocite thingsthattheoperational or development environmentis to providetothe
capability being specified. For example, Thevehicle'sexhaustsystem will power theABC widget.
Should Not used often as an imperative in SRS statements; however, when used, theSRSstatement
always readsweak. Avoid using Should in your SRSs.

13. 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 Initialization
• When the status of an external interface has changed
• When a report has been requested
Ø These are actually three requirements
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 13
Requirements Specification

14. 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. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 14
Requirements Specification

15. 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 all 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-ProjID-Version-Date.docx
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 15
Requirements Specification

16. 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. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 16
Requirements Specification

17. 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 of the requirements and Object of the action
• Actions: What the subject does, contains an imperative
• Conditions: What must be in place in order for the action to take place
• Constraints: Qualifies the action, performance
• Example:
• When signal x is received, the system shall set the signal x received bit within 2
seconds
13. Design for asset reuse
14. Finding the right combination of approaches for the development process
• X-driven development
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 17
Requirements Specification

18. 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
write 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. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 18
Requirements Specification

19. MedTech
References
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 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