Chapter 3 - Requirement Engineering
Chapter 3 - Requirement Engineering
Chapter 3 - Requirement Engineering
Requirement Engineering/
Elicitation
Topics to be covered
SRS
What is a requirement?
The software requirements are description of features and
functionalities of the target system and needed by a user to solve a
problem or achieve an objective.
A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed documents.
The process of establishing the services that the customer requires
from a system and the constraints under which it operates and is
developed.
The requirements for a system are the descriptions of what the
system should do—the services that it provides and the
constraints on its operation..
Types of Software Requirements
The requirements, which are commonly considered, are classified
into three categories, namely:
1. Functional requirements:
2. Non-functional requirements
3. Domain requirements
Types of Software Requirements
Functional requirements
IEEE defines functional requirements as ‘a function that a system or
component must be able to perform.’ These requirements describe
the interaction of software with its environment and specify the
inputs, outputs, external interfaces, and the functions that should be
included in the software. These are statements of services the system
should provide, how the system should react to particular inputs, and
how the system should behave in particular situations.
It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what
function a system is likely to perform.
Functional requirements expressed in user stories, features, and
capabilities represent most of the work in building solutions that
deliver value to the user. Functional Requirements are also called
Functional Specification.
Types of Software Requirements
Functional requirements
Functional requirements can be consider in to the following groups:
Business requirements. describe why the organization is undertaking the
project. This usually contains the ultimate goal, such as an order system,
approval workflows, an online catalogue, or a physical product.
Administrative functions. These are the routine things the system will do,
such as reporting.
User requirements. referred to as user needs, describe what the user does
with the system, such as what activities that users must be able to perform,
such as place an order or browse the online catalogue.
System requirements. are the building blocks developers use to build the
system. These are the traditional “shall” statements that describe what the
system “shall do” .These are things like software and hardware
specifications, system responses, or system actions.
Types of Software Requirements
Functional requirements should include the following
things:
Details of operations conducted in every screen
Data handling logic should be entered into the system
It should have descriptions of system reports or other outputs
Complete information about the workflows performed by the system
It should clearly define who will be allowed to create/modify/delete
the data in the system
How the system will fulfill applicable regulatory and compliance
needs should be captured in the functional document.
The functional requirements should be complete and
consistent.
Completeness implies that all the user requirements are defined.
Consistency implies that all requirements are specified clearly
without any contradictory definition.
Examples of functional requirements
The list of examples of functional requirements
includes:
Business Rules
Transaction corrections, adjustments, and cancellations
Administrative functions
Authentication
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Types of Software Requirements
Nonfunctional Requirements
A non-functional requirement defines the quality attribute of a
software system. They represent a set of standards used to judge
the specific operation of a system.
Defines how a system is supposed to be. They are user visible
aspects of the system not directly related to functional behavior of
the system.
Nonfunctional requirements are other properties or characteristics
that the system must have, other than its basic functionality.
A non-functional requirement is essential to ensure the usability
and effectiveness of the entire software system. Failing to meet
non-functional requirements can result in systems that fail to
satisfy user needs.
Non-functional requirements are product properties and focus on
user expectations.
Types of Software Requirements
Nonfunctional Requirements
They are implicit or expected characteristics of software, which
users make assumption of.
Product requirements
Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
Organisational requirements
Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Non-functional classifications
Nonfunctional Requirements
Non-functional classifications
Security Cost
Logging Interoperability
Storage Flexibility
Configuration Disaster recovery
Performance Accessibility
Examples of non-functional requirements
Here, are some examples of non-functional requirement:
1. Users must change the initially assigned login password
immediately after the first successful login. Moreover, the initial
should never be reused.
2. Employees never allowed to update their salary information. Such
attempt should be reported to the security administrator.
3. Every unsuccessful attempt by a user to access an item of data shall
be recorded on an audit trail.
4. A website should be capable enough to handle 20 million users with
out affecting its performance
5. The software should be portable. So moving from one OS to other
OS does not create any problem.
6. Privacy of information, the export of restricted technologies,
intellectual property rights, etc. should be audited.
Types of Software Requirements
Domain requirements:
Domain requirements may be new functional requirements,
constraints on existing requirements or define specific computations.
They are important because they often reflect fundamentals of the
application domain.
Domain requirements reflect the environment in which the system
operates so, when we talk about an application domain we mean
environments such as train operation, medical records, e-commerce etc.
When domain requirements are not expressed clearly, it can result in the
following difficulties.
Understandability
When domain requirements are specified in the language of application
domain (such as mathematical expressions), it becomes difficult for software
engineers to understand them.
Implicitness
When domain experts understand the domain requirements but do not
express these requirements clearly, it may create a problem (due to
incomplete information) for the development team to understand and
implement the requirements in the system.
why requirements elicitation is difficult:
15
Requirements gathering - The developers discuss with the client and end
users and know their expectations from the software.
Organizing Requirements - The developers prioritize and arrange the
requirements in order of importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, it is then negotiated and
discussed with the stakeholders. Requirements may then be prioritized and
reasonably compromised.
Documentation - All formal and informal, functional and non-functional
requirements are documented and made available for next phase processing.
RE Process-Requirements elicitation Techniques
Once requirements sources have been identified, the software
engineer can start eliciting requirements from them. Even if
sources are cooperative and articulate, the relevant information
must be captured.
A variety of techniques can be used such as:
Brainstorming
Interviews
Questionnaires
Prototypes
Scenarios
Facilitated
meetings
Observation
RE Process-Requirements elicitation Techniques
Brainstorming- Planned brainstorming generates a few imaginative
ideas around a specific key demand or territory.
Interviews– Talk with stakeholders who you think can give essential
knowledge into the requirements.
Questionnaires- is a research instrument consisting of a series of
questions for the purpose of gathering information from respondents.
Prototypes– From paper mock-ups of screen designs to beta-test
versions of software products.
Scenarios – Provides a context for elicitation of user requirements.
Asks ‘what if’ and ‘how is this done’ questions
The most common type of scenario is the use case ("who" can do
"what" with the system in question).
Facilitated meetings –A group of people may bring more insight to
achieve a summative effect to the requirements
Observation – Software engineers are immersed in the environment
to observe the user interact between the software and other users
RE Process-Requirements analysis
Requirements analysis: IEEE defines requirements analysis as
The process of studying user needs to arrive at a definition of a
system, hardware or software requirements.
Requirements analysis helps to understand, interpret, classify, and
organize the software requirements in order to assess the feasibility,
completeness, and consistency of the requirements.
The process of reasoning about the requirements that have been
elicited; it involves activities such as examining requirements for
conflicts or inconsistencies, combining related requirements and
identifying missing requirements.
The goal of analysis is to discover problems, incompleteness and
inconsistencies in the elicited requirements.
Assessing if the system is useful to the business (feasibility study),
RE Process-Requirements analysis
After
requirement gathering, requirement analysis is done to check
on why the product is needed. Requirement analysis includes:
Necessity checking – requirements that don’t contribute to the business
goals of the organization or specific problem that has to be addressed
by the system are checked for necessity for the development of the
system.
Consistency and completeness checking – no contradictions and
feasibility checking in terms of budget and schedule.
Requirement discussion – highlight the requirement and discussion of
problematic elements through introspection and interviews.
Requirement prioritization – requirements are prioritized based on
criticality and the highly complex and critical activities are identified
for risk plot and low level activities are considered for easy
implementation.
Requirement agreement – compromised set of requirements based on
feasibility checking.
Analysis model is built incrementally and iteratively.
RE Process-Requirements specification
Requirement specification describes clearly and accurately each of the
essential requirements (functions, performance, design constraints, and
quality attributes) of the system and its external interfaces.
Requirements specification is the process of writing down the user and
system requirements in a requirements document.
User requirements have to be understandable by end-users and customers
who do not have a technical background.
System requirements are more detailed requirements and may include
more technical information.
Specification involves representing and storing the collected requirements
knowledge in a persistent and well-organized fashion that facilitates
effective communication and change management. Use cases, user
stories, functional requirements, and visual analysis models are popular
choices for requirements specification.
RE Process-Requirements specification
A software requirements specification (SRS) is a document that
captures complete description about how the system is expected to
perform. It is usually signed off at the end of requirements engineering
phase.
SRS defines how the intended software will interact with hardware,
external interfaces, speed of operation, response time of system,
portability of software across various platforms, maintainability, speed of
recovery after crashing, Security, Quality, Limitations etc. Converting
these requirements into some standard form (specification/SRS),
SRS should come up with the following features:
User Requirements are expressed in natural language.
Technical requirements are expressed in structured language, which is
used inside the organization.
Design description should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
RE Process-Requirement Validation
Requirements validation is the process of checking that
requirements defined for development, define the system that the
customer really wants. After requirement specifications are
developed, the requirements mentioned in this document are
validated.
We usually use requirements validation to check error at the initial
phase of development as the error may increase excessive rework
when detected later in the development process.
User might ask for illegal, impractical solution or experts may interpret
the requirements inaccurately. This results in huge increase in cost if
not nipped in the bud.
Validation involves techniques to confirm that the correct set of
requirements has been specified to build a solution that satisfies the
project's business objectives.
RE Process-Requirement Validation
Requirements validation can be checked against following criteria:
Correctness:
The requirements should reflect the actual needs of the stakeholders.
A specification is correct if it represents accurately the system that
the client needs and that the developers intend to build.
Completeness:
They should include descriptions of all facilities/services required.
It is complete if all possible scenarios through the system are
described, including exceptional behavior.
Consistency:
There should be no conflicts or contradictions in the descriptions of
the system facilities.
Unambiguous/Clarity:
A requirement cannot be interpreted in two mutually exclusive ways.
The requirements specification is unambiguous if exactly one
system is defined.
30
RE Process-Requirement Validation
Realism:
Requirements can be implemented and delivered
The requirements specification is realistic if the system can be
implemented within constraints.
Verifiability/Measurable / Testable :
The requirements specification is verifiable if, once the system is
built, repeatable tests can be designed to demonstrate that the system
fulfills the requirements specification.
Traceability
A requirements specification is traceable if each requirement can be
traced throughout the software development to its corresponding
system functions, and if each system function can be traced back to
its corresponding set of requirements.
31
RE Process-Requirement Validation Techniques
There are some techniques you can use to validate the
requirements, and you may use one or more of them together,
depending on your needs. Requirements validation techniques:
Requirements reviews
Prototyping
Model validation
Test-case generation
RV/Requirements Reviews
A systematic manual analysis of the requirement. Validation often
done by inspection or reviews of requirements documents.
Reviewers look for errors, mistaken assumptions, lack of clarity,
and deviation from standard practice.
Regular reviews should be held while the requirements definition
is being formulated. What to look for:
Verifiability: is the requirement realistically testable?
Comprehensibility: is the requirement properly understood?
Traceability: is the origin of the requirement clearly stated?
Adaptability: can the requirement be changed without a large
impact on other requirements?
RV/Prototyping
In this approach to validation, an executable model of the system
is demonstrated to the customer and end users to validate, and
ensure if it meets their needs.
Prototyping is usually used when the requirements aren’t clear. So,
we make a quick design of the system to validate the requirements.
If it fails, we then refine it, and check again, until it meets the
customer needs.
This definitely will decrease the cost as a result of having a clear,
understandable, consistent requirements.
RV/Model Validation
Model validation is defined as “the set of processes and
activities intended to verify that models are performing as
expected, in line with their design objectives, and business
uses.”
It also identifies “potential limitations and assumptions, and
assesses their possible impact.” Validation activities are
performed by individuals independent of model development or
use.
Validating the quality of models developed during analysis by
checking different validation criteria.
RV / Test-case generation
Test case generation is the process of building test suites for
detecting system errors. A test suite is a group of relevant test
cases bundled together. Developing tests for requirements to
check testability.
The requirements specified in the SRS document should be
testable. Test case generation is the most important and
fundamental process of software testing.
Requirements Engineering Process
Refining use cases- During this activity, developers ensure that the
requirements specification is complete by detailing each use case
and describing the behavior of the system in the presence of errors
and exceptional conditions.
Identifying relationships among use cases- During this activity,
developers identify dependencies among use cases. They also
consolidate the use case model by factoring out common
functionality.
This ensures that the requirements specification is consistent.
Identifying nonfunctional requirements- During this activity,
developers, users, and clients agree on aspects that are visible to the
user, but not directly related to functionality. These include
constraints on the performance of the system, its documentation, the
resources
39 it consumes, its security, and its quality.
i) Identifying Actors
This serves both to define the boundaries of the system and to find all the viewpoints from
which the developers need to consider the system.
Actors are outside of the system boundary- they are external Subsystems and objects are inside
the system boundary- they are internal
To identify an actor, search in the problem statement for business terms that represent
roles in the system. For example, in the statement "patients visit the doctor in the clinic
for medical tests," "doctor" and "patients" are the business roles and can be easily
identified as actors in the system.
Questions for identifying actors
Which user groups are supported by the system to perform their work?
Which user groups execute the system’s main functions?
Which user groups perform secondary functions, such as maintenance and administration?
With what external hardware or software system will the system interact?
40
Actors are role abstractions and do not necessarily directly map to persons
Example- Accident Management System
41
ii) Identifying Scenarios
47
Observations about “Warehouse on
Fire”
… ok, but we have even more scenarios available and
identified:
Report fire in a car
Report flat on fire
Report truck on fire
48
iii) Identifying Use Cases
49
Use Case:
Example – Report Emergency
The Fireman on duty notices a fire incident. The Fireman or his Replacement (hereafter
termed Initiator) reports the emergency from their car by using the SYSTEM.
The Initiator enters the address of the corresponding fireplace, a brief description of its
location (i.e., north west corner), and an emergency level. In addition to a fire unit, the
Initiator requests several paramedic units on the scene. He confirms his input and waits
for an acknowledgment.
The Dispatcher on duty, is alerted to the emergency by a beep of his workstation. He
reviews the information submitted by the Initiator and acknowledges the report. He
allocates a fire unit and a suitable number of paramedic units to the Incident site and
sends their estimated arrival time back to the Initiator.
The Initiator receives the acknowledgment and the ETA.
50
Observations about “Report
Emergency”
51
From Scenarios to use cases
Use case
“ReportEmergency”
________________
“ReportEmergency”
_________________
________________
52
Order of steps when formulating use cases
First step: Name the use case
Use case name: ReportEmergency ( Report who, what)
Second step: Find the actors
Generalize the concrete names (“Bob”) to participating actors (“Field officer”)
Participating Actors:
Field Officer (Bob and Alice in the Scenario)
Dispatcher (John in the Scenario)
Third step: Concentrate on the flow of events
Use informal natural language
53
Use case flow of events
Use case Name ReportEmergency
55
Cont’d
The causal relationship between successive steps should be clear.
A use case should describe a complete user transaction (e.g., the
ReportEmergency use case describes all the steps between initiating
the emergency reporting and receiving an acknowledgment).
Exceptions should be described separately.
A use case should not describe the user interface of the system. This
takes away the focus from the actual steps accomplished by the user
and is better addressed with visual mock-ups (e.g., the
ReportEmergency only refers to the “Report Emergency” function,
not the menu, the button, nor the actual command that corresponds to
this function).
A use case should not exceed two or three pages in length. Otherwise,
use include and extend relationships to decompose it in smaller use
cases
56
iv) Identifying Relationships among Actors and Use Cases
Relationships among actors and use cases enable the developers
and users to reduce the complexity of the model and increase its
understandability
Relationship between an actor and use case communication
relationships
Relationship between use cases include relationships (to
reduce redundancy among use cases) and extended relationships
(to separate exceptional and common flows of events)
57
Cont’d
58
v) Identifying Nonfunctional Requirements
Nonfunctional requirements describe aspects of the system that
are not directly related to its functional behavior.
Nonfunctional requirements span a number of issues, from user
interface look and feel to response time requirements to security
issues
59
Examples of non functional requirements
Usability
What is the level of expertise/ know-how of the user?
What user interface standards are familiar to the user?
What documentation should be provided to the user?
Reliability (including robustness, safety, and security)
How reliable, available, and robust should the system be?
Is restarting the system acceptable in the event of a failure?
How much data can the system loose?
How should the system handle exceptions?
Are there safety requirements of the system?
Are there security requirements of the system?
Performance
How responsive should the system be?
Are any user tasks time critical?
How many concurrent users should it support?
How large is a typical data store for comparable systems?
60
Case Study
For our case study, we will be the architects assigned the task of constructing the
design elements for a system that can be used to manage courses/classes for an
organization that specializes in providing training. Let us name the system that we will
be designing as the Courseware Management System. The organization offers a variety
of courses in a variety of areas such as learning management techniques and
understanding different software languages and technologies. Each course is made up
of a set of topics. Tutors in the organization are assigned courses to teach according to
the area that they specialize in and their availability. The organization publishes and
maintains a calendar of the different courses and the assigned tutors every year. There
is a group of course administrators in the organization who manage the courses
including course content, assign courses to tutors, and define the course schedule. The
training organization aims to use the Courseware Management System to get a better
control and visibility to the management of courses as also to streamline the process
of generating and managing the schedule of the different courses.
The organization allow regular and extension students to register for training course
online and to pay for courses by Credit Card, by Cash, by Check etc.
Now that we have our problem statement defined, we can proceed to the next
step—analyzing and elaborating on the requirements(requirement elicitation
activities) and then designing the Courseware Management System.
61
UML Case study—Courseware Management
System
We will now design the use case model for the Courseware Management System
case study.
Analyze the problem statement to identify the potential actors and use cases of the
system. First, let us list the potential actors.
A quick look at the problem statement shows up the following terms and entities
specific to the system:
Courses and Topics that make up a course
Tutors who teach courses
Course administrators who mange the assignment of the courses
to tutors
Calendar or Course Schedule is generated as a result of the
Students who refer to the Course schedule or Calendar to decide
which courses they wish to take up for study
Identifying Actors of the Courseware Management System
The entities that perform action will be the actors for the
Courseware Management System.
From carefully study of the problem, the actors that we can identify are:
Tutors
Course administrators
Students
A primary actor among these is:
Course administrators
Identifying Use Cases of the Courseware Management System
Next, let us identify the potential business processes in the Courseware Management
System.
The primary business flows in the system are:
Manage courses
Manage course assignments
We can further divide the above two business flows into sub flows:
So, within the "Manage courses" use case, we can identify the following sub processes:
View courses
Manage topics for a course
Manage course information
the use cases that we have identified within the "Manage course assignment" use case
are:
View course calendar
View tutors
Manage tutor information
Assign courses to tutors
UCD
The final list of use cases for the courseware management system will now be:
View courses
Manage topics for a course
Manage course information
View course calendar
View tutors
Manage tutor information
Assign courses to tutors
REGISTER ONLINE
PAYMENT
Example 2: Point of Sell (POS) System in Minimar
Writing a Use Case Specification
A use case diagram, as we have seen, is a visual depiction of
the different scenarios of interaction between an actor and a
use case. The usefulness of use case diagrams is more as a
tool of communication between the requirements capture
team and the user group.
The next step after finalizing of use case diagrams is to document the
business functionality into clear-cut and detailed use case
specifications. Because use cases are used as an input to the other
project phases such as design, development, and testing, we need to
ensure that the visual depiction of the business requirements is
translated into clear and well-defined requirements in the form of use
case specifications. Elaborate use case specifications are used as an
input for design and development and for writing test cases (unit,
system,
67 and regression tests, as the case may be).
Cont..
A use case specification document should enable us to easily document the business
flow. Information that you document in a use case specification includes what actors are
involved, the steps that the use case performs, business rules, and so forth.
A use case specification document should cover the following areas(use case
specification document contents):
• Use Case Name: Give a short, descriptive name to the use case
• Actors: List the actors that interact and participate in this use case.
• Description: Give a short informal description
• Trigger: Describe the event that initiates the activity
68
Use case specification document
contents…
Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.
Post-conditions: Define the different states in which you expect the system to be in,
after the use case executes.
Basic Flow: List the basic events that will occur when this use case is executed.
Include all the primary activities that the use case will perform.
Alternative flows: Any subsidiary events that can occur in the use case should be
listed separately. Each such event should be completed in itself to be listed as an
alternative flow. A use case can have as many alternative flows as required. But
remember, if there are too many alternative flows, you need to revisit your use case
design to make it simpler and, if required, break the use case into smaller discrete
units.
Special Requirements: Business rules for the basic and alternative flows should be
listed as special requirements in the use case narration. These business rules will also
be used for writing test cases. Both success and failure scenarios should be described
here.
Use case relationships: For complex systems, it is recommended that you document
the relationships between use cases. If this use case extends from other use cases or
includes the functionality of other use cases, these relationships should be listed here.
Requirements Validation
70
Requirements Management
Functional requirements:
Store the requirements in a shared repository
Provide multi-user access to the requirements
Automatically create a specification document from the requirements
Allow change management of the requirements
Provide traceability of the requirements throughout the artifacts of the system.
Use Case Templates – Simple Column Form
Linear sequences (main and alternatives)
ATMs + ATM
ATMs
Bank Software
1 2 3
- Customer - Customer - Card reader
- Bank - Cash dispenser
- Key pad
- Touch screen
- Printer
- Bank
Use Case Development – Example: ATM System
(2)
2. Identify actors
Who interacts with the system? Example ATM with scope 2
Who or what uses the system?
For what goals? Bank Customer
What roles do they play?
4. Identify preconditions
e.g., preconditions of use case Withdraw Cash
System is in operation, cash is available
Use Case Development – Example: ATM System
(6)
Withdraw Cash
<<include>> <<include>>
Customer
Make Deposit
Print Account Statement
Example 1
80
Name: Enroll in University
Identifier: UC 19
Goal: Enroll applicant in the university
Preconditions:
The Registrar is logged into the system.
The Applicant has already undergone initial checks to verify that they are eligible to enroll.
Postconditions:
The Applicant will be enrolled in the university as a student if they are eligible.
81
Main Flow:
1. An applicant wants to enroll in the university.
2. The applicant hands a filled out copy of form UI13 University Application Form to the
registrar.
3. The registrar visually inspects the forms.
4. The registrar determines that the forms have been filled out properly.
5. The registrar selects to Create New Student.
6. The system displays the Create Student Screen.
7. The registrar inputs the name, address, and phone number of the applicant.
[Extension Point: XPCheck]
8. The system determines that the applicant does not already exist within the system.
9. The system determines that the applicant is on the eligible applicants list.
10. The system adds the applicant to its records.
11. The registrar enrolls the student in courses via use case UC 17 Enroll in
Course.
12. The system prepares a bill for the applicant enrollment fees.
Alternate Flows:
4.a The forms have not been adequately filled…
82
Name: Perform Security Check
Identifier: UC 34
At Extension Point XPCheck:
1. The registrar asks for security check results about applicant.
2. The system asks RCMP Security System for applicant security check results.
3. The RCMP Security System responds that applicant has been cleared.
3.a The Security System responds that applicant has not been cleared
83
The software requirements document
A software requirements document (also known as software
requirements specifications) is a document that describes the intended use-case,
features, and challenges of a software application.
The output of the requirements phase of the software development process
is Software Requirements Specification (SRS) (also known
as requirements document). This document lays a foundation for software
engineering activities and is created when entire requirements are elicited and
analyzed. SRS is a formal document, which acts as a representation of software
that enables the users to review whether it (SRS) is according to their
requirements. In addition, it includes user requirements for a system as well as
detailed specifications of the system requirements.
IEEE defines software requirements specification as, ‘a document that clearly
and precisely describes each of the essential requirements (functions,
performance, design constraints and quality attributes) of the software and the
external interfaces. Note that requirements specification can be in the form of a
written document, a mathematical model, a collection of graphical models, a
prototype, and so on.
Why software document requirements?
Softwarerequirement documents provide an important map of
the product being built, the features that will be included, and
much more.
Roadmap helps to keep the technical and non-technical team on
the same wavelength as to what the expectations are.
Helps to ensure that the product is built meeting the needs
whether it’s for internal purposes, for users or clients.
Serves as a contract between the customer and the developer.
Serves as a source of test plans.
Servesto specify project goals and plan development cycles and
increments.
The software requirements document
Characteristics of SRS
Complete
Consistent
Correct
Modifiable
Ordered
Testable
Traceable/ Visible
Unambiguous/clear
Valid
Verifiable
Users of a software requirements document
The software requirements document Structure
Since the requirements document serves as a foundation for
subsequent software development phases, it is important to develop
the document in the prescribed manner. For this, certain guidelines
are followed while preparing SRS. These guidelines are listed below.
Functionality: It should be separate from implementation.
Analysis model: It should be developed according to the desired
behavior of a system. This should include data and functional response
of a system to various inputs given to it.
Cognitive model: It should be developed independently of design or
implementation model. This model expresses a system as perceived by
the users.
The content and structure of the specification: It should be flexible
enough to accommodate changes.
Specification: It should be robust. That is, it should be tolerant
towards incompleteness and complexity.
Requirements document structure
Software Requirements Document Contents
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirements
Requirements document structure
Software Requirements Document Contents
1. Introduction
1.1 Purpose: Set the expectations for the outcome of the product.
1.2 Intended Audience: Who is the software for? Who is the end-user? Will the software be used internally at a company or
externally?
1.3 Intended Use: What is the software for? What problem is it solving?
1.4 Scope: Explain the scope of the software. What are the main goals and objectives? How do they relate to the company’s goals?
1.5 Definitions and Acronyms: Provide an overview of any definitions the reader should understand before reading on.
2. Overall Description: Describe what you are building and for who.
2.1 User Needs: Explain the user needs for this software.
2.2 Assumptions and Dependencies: What assumptions are you making that could cause an error in your approach? Is the project
reliant on any other factors that could affect the development of the software?
3. System Features and Requirements
3.1 Functional Requirements: Take time to define the functional requirements that are essential for the software to build.
3.2 External Interface Requirements: Are there any UX and UI requirements that you must keep in mind as you build?
3.3 System Features: What features are required for the software to even work.
3.4 Nonfunctional Requirements: Are there any non-functional requirements that you need to address (i.e. budget, team, etc.)
The end!!!
91