Software Requirements
Specification
A deeper dive on how to write requirements
Requirements Elicitation
Requirements Elicitation and Validation
● After you study project description
○ You explore the domain and look for similar work
○ Prepare questions
○ Meet with the Customer to resolve questions and gain more information
● Prepare initial requirements
● Validate requirements
○ Validate that you correctly understood
● Revise requirements
Validate requirements
Scenarios : real-life examples that include
● Initial situation
● Normal flow of events
● What can go wrong
● Information about other concurrent activities
● Terminating situation
Requirements engineering 4
Scenario development
● Consider cases that are representative of a real context
● A user
○ Name
○ Relevant characteristics
○ Role
● A use case
○ Reason for use
○ What they do
○ What the system does
○ Build a case that demonstrates how the feature would be used
● The data you use should be realistic
○ I.e. Sandra Brown (not user1), wants to find a recipe for “Mississippi Mud Pie” (not some recipe).
○ Definitely no data that looks like: test1, t1, asasfasgasf, asdf, date
Validation Session
● You present the customer your scenarios
● Pay very careful attention to what the customer:
○ Says
○ Doesn’t say
○ Does
○ Looks (happy, uninterested, confused) – non verbal cues should be observed and followed up
● Take careful notes
● Meet with your team to decide actions to be taken
Writing the SRS
Most everything depends on the requirements
● SRS serve as
○ very important references
○ communication
● They must be written well
○ Clear
○ Comprehensive
○ Consistent
● There are standards for writing requirements, 29148-2011 -
ISO/IEC/IEEE International Standard - Systems and software
engineering -- Life cycle processes --Requirements engineering
Nothing in Software Development is Static
● Things change
● We try to manage the change - minimize it
● There will be revisions
● Ideally requirements won’t change - not realistic
● The changes should greatly reduce
○ Good elicitation
○ Change management (carefully consider change requests)
SRS are very comprehensive
● We will focus on the core parts of SRS
● The deliverable form of requirements will package the requirements that you
have prepared.
● The followings slides detail the essential parts
● You are free to include other parts based on the standards
● The terms enclosed with “<” and “>” indicate
○ parts that are specific to your project
○ You will fill them appropriately
Title Page
Software Requirements Specification
for
<Project Name>
<Version>
<Date>
Prepared by:
<Group Name>
<Member Names>
Prepared for:
<Course Name and Semester>
Table of Contents
● A table indicating the contents of the SRS including
○ Revision History
○ Introduction
○ Overall Description
○ System Features (Functional Requirements)
○ Nonfunctional Requirements
○ Appendix
Revision History
● Periodically you will have versions that serve as references
● For each version you keep a record
● The summary is shown in that table at the beginning
● The remainder document covers the most recent version
Name Date Reason for Change Version
Introduction
● Purpose
<Brief description of the product being specified>
● Document conventions
<Any documentation convention that the reader needs to know>
● Product scope
<A short description of the software and its purpose. What are its objectives and
goals. What are its benefits?>
● References
<Any resources referenced in this specification>
System Features / Functional Requirements
● <Feature description> and <priority> (high, medium, low)
● <Stimulus/Response>
○ A description of user interactions and system responses
● <Precondition> and <Post Conditions>
○ What must be true before and after this feature is performed
● <Functional Requirements>
○ (see next slide)
Feature - Functional Requirements
● All the requirements associated with this feature
● These functionalities must be implemented in order for user to perform this feature
● Include error conditions
● Remember: Each requirement
● Unique ID ● Unambiguous
● Concise ● Verifiable
● Complete ● Necessary
Non functional requirements
● Performance
● Safety
● Security & Privacy
● Quality
○ aspects that are important for developers and/or customers for a quality product.
○ i.e.: availability, interoperability, maintainability, portability, reusability, robustness, usability.
Others
● Appendix A: Glossary
<All the project specific terms that need to be correctly interpret the SRS>
● Appendix B:
● …
Always pay attention to verifiability
The system should be easy to use by schedule administrations and it
should minimize errors.
NOT VERIFIABLE
Good ? Or Not good? Why?
Always pay attention to verifiability
Experienced schedule administrators should be able to use all system
functions after a training that does not exceed two hours. After receiving
the training, the average number of errors made by schedule
administrators should not exceed one per hour.
GOOD BECAUSE VERIFIABLE AND SPECIFIC
Good ? Or Not good? Why?
Example: Access the following specification
A user shall be able to follow and rate other users.
AMBIGUOUS, NOT DETAILED ENOUGH RATING HOW?
Good ? Or Not good? Why?
Acceptance Criterion
A predefined set of conditions agreed upon by a team that determines whether a
specific feature is completed.
Example: Acceptance criterion
REQ 1: Follow another user
Description:
Users shall be able to follow another user where the initiating user is a follower, and the target
user is `being followed’.
Acceptance Criteria:
1. When a user follows another user, the system shall add the initiating user to the target
user’s "Followers" list.
2. The system shall add the target user to the initiating user’s "Following" list.
3. The system shall ensure that the follow relationship is stored persistently.
Glossary
Specific project related terms, such as follower, following, friend, reshare, student, …
Create a glossary and use them in your requirements.
How can we improve it? Let’s do it together!
A user shall be able to follow and rate other users.
Summarize: A good SRS should be
● Correct ● Prioritized
● Complete ● Verifiable
● Consistent ● Modifiable
● Unambiguous ● Traceable
What we have learned
● Reviewed requirements specification
● Explored additional details about writing requirements
● Preparing SRS specification
● Next: Move on
