Module - 1 • Software requirements specification

• Eliciting Software requirements

• Requirement specifications

• Software requirements engineering

concepts

• Requirements modelling

• Use cases and User stories.

• Requirements documentation.
 Software Requirements Specification
(SRS)
• A requirement can range from a high-level, abstract statement of a service or
constraint to a detailed, formal specification.
• SRS is the set of activities designed to capture behavioural and
non-behavioural aspects of the system in the SRS document.
• The goal of the SRS activity, and the resultant documentation, is to provide a
complete description of the system’s behaviour without describing the internal
structure.
• This aspect is easily stated, but difficult to achieve.
• Software specifications provide the basis for analysing the requirements,
validating that they are the stakeholder’s intentions, defining what the
designers have to build, and verifying that they have done so correctly.

• SRSs allow us to know the motivation for development of the software

system.

• Software requirements also help software engineers manage the evolution

of the software over time and across families of related software
products.
 Requirements Engineering Activities
• First, we must elicit the requirements, which is a form of discovery.

• The term “gathering” is also used to describe the process of collecting software

requirements.

• Often, requirements are deeply hidden, expressed incorrectly by stakeholders,

contradictory, and complex.

• Eliciting requirements is one of the hardest jobs for the requirements engineer.
• Modeling requirements involves representing the requirements in some
form.

• Words, pictures, and mathematical formulas can all be used but it is never
easy to effectively model requirements.

• Analysing requirements involves determining if the requirements are

correct or have certain other properties such as consistency, completeness,
sufficient detail, and so on.

• Finally, requirements change all the time and the requirements engineer must
be equipped to deal with this eventuality.
• SRSs are usually classified in terms of their level of abstraction:

1. user requirements

2. system requirements

3. software design specifications

• User requirements specifications are usually used to attract bidders, often
in the form of a request for proposal (RFP).
• User requirements may contain abstract statements in natural
language with accompanying informal diagrams.
• User requirements specify functional and non-functional
requirements as they pertain to externally visible behaviour in a form
understandable by clients and system users.
• System level requirements, or SRSs mentioned previously, are detailed
descriptions of the services and constraints.
• Systems requirements are derived from analysis of the user
requirements.
• Systems requirements should be structured and precise because they act
as a contract between client and company (and can literally be enforced
in court).
• Software design specifications are usually the most detailed level
requirements specifications that are written and used by software
engineers as a basis for the system’s architecture and design.

• The user needs are usually called “functional requirements” and the
external constraints are called “non-functional requirements.”
• Functional requirements: describe the services the system should provide.

• Sometimes the functional requirements state what the system should not do.

• Functional requirements can be high-level and general or detailed, expressing

inputs, outputs, exceptions, and so on.

• Non-functional requirements: are imposed by the environment in which the

system is to exist.

• These requirements could include timing constraints, quality properties,

standard adherence, programming languages to be used, compliance with laws, and
so on.
Functional requirements Non-Functional requirements
• Interface specifications • Domain requirements
• Performance requirements • Design constraint requirements
• Logical database
requirements
• System attribute
requirements
• Interface specifications are functional software requirements specified in
terms of interfaces to operating units.

• Most systems must operate with other systems and the operating interfaces
must be specified as part of the requirements.

• There are three types of interface that may have to be defined: procedural
interfaces, data structures that are exchanged , and data representations.

• System attribute requirements are functional requirements that include

reliability, availability, security, maintainability, and portability.
• Performance requirements are functional requirements that include the
static and dynamic numerical requirements placed on the software or on
human interaction with the software as a whole.

• Logical database requirements are functional requirements that include

the types of information used by various functions such as frequency of use,
accessing capabilities, data entities and their relationships, integrity
constraints, and data retention requirements (Data retention refers to the
practice of storing data for a specific period of time for legal compliance,
business continuity, and data analytics.)
• Domain requirements are a type of non-functional requirement from
which the application domain derives.
• For example, in the baggage inspection system, industry standards
and restrictions on baggage size and shape will place certain
constraints on the system.

• Design constraint requirements are non-functional requirements that

are related to standards compliance and hardware limitations.
What is a feasibility study and what is its role?

• A feasibility study is a short focused study that checks if the system

contributes to organisational objectives the system can be engineered using

current technology and within budget the system can be integrated with

other systems that are used.

• A feasibility study is used to decide if the proposed system is worthwhile.

• Feasibility studies can also help answer some of the following questions.

1. What if the system wasn’t implemented?

2. What are current process’s problems?

3. How will the proposed system help?

4. What will be the integration problems?

5. Is new technology needed? What skills?

6. What facilities must be supported by the proposed system?

 Requirements elicitation
• Requirements elicitation involves working with customers to determine the
application domain, the services that the system should provide, and the
operational constraints of the system.

• Elicitation may involve end-users, managers, engineers involved in

maintenance, domain experts, trade unions, and so on. These people are
collectively called stakeholders.

• But stakeholders don’t always know what they really want.

• The software engineer has to be sensitive to the needs of the stakeholders
and aware of the problems that stakeholders can create including: expressing
requirements in their own terms
o providing conflicting requirements
o introducing organisational and political factors, which may influence the system
requirements
o changing requirements during the analysis process due to new stakeholders who may
emerge and make changes to the business environment

• The software engineer must monitor and control these factors throughout the
requirements engineering process.
The following three approaches to requirements elicitation will be
discussed in detail:

• Joint application design (JAD)

• Quality function deployment (QFD)

• Designer as apprentice
 JAD

• Joint application design (JAD) involves highly structured group

meetings or mini-retreats with system users, system owners, and
analysts in a single room for an extended period.

• These meetings occur four to eight hours per day and over a period
lasting one day to a couple of weeks.
Software engineers can use JAD for:
i. eliciting requirements and for the SRS
ii. design and software design description
iii. code
iv. tests and test plans
v. user manuals
•Planning for a review or audit session involves
three steps:
i. selecting participants
ii. preparing the agenda
iii. selecting a location
 Rules for JAD sessions
The session leader must make every effort to ensure that these practices are implemented.

• Stick to the agenda.

• Stay on schedule

• Ensure that the scribe is able to take notes.

• Avoid technical jargon.

• Resolve conflicts.

• Encourage group consensus.

• Encourage user and management participation without allowing individuals to

dominate the session.

• Keep the meeting impersonal.

 Quality function deployment (QFD)
• QFD was first developed in Japan by Yoji Akao in the late 1960s while
working for Mitsubishi’s shipyard.

• It is a technique for determining customer requirements and defining major

quality assurance points to be used through-out the production phase.

• QFD provides a structure for ensuring that customers’ wants and needs are
carefully heard, and then directly translated into a company’s internal
technical requirements from analysis through implementation to
deployment.
• The basic idea of QFD is to construct relationship matrices between
customer needs, technical requirements, priorities, and
competitor assessment.

• These relationship matrices are often represented as the roof, ceiling,

and sides of a house, QFD is sometimes referred to as the “house of
quality”
Advantages of QFD
• QFD improves the involvement of users and managers.

• It shortens the development life cycle and improves overall project

development.

• QFD supports team involvement by structuring communication

processes.

• It provides a preventive tool to avoid the loss of information.

 Designer as apprentice
• Designer as apprentice is a requirements discovery technique in which the requirements engineer

“looks over the shoulder” of the customer to enable the engineer to learn enough about the work

of the customer to understand his needs.

• The relationship between customer and designer is like that between a master craftsman and

apprentice.

• The apprentice learns a skill from the master just as we want the requirements engineer (the

designer) to learn about the work from the customer.

• The apprentice is there to learn whatever the master knows.

• The designer must understand the structure and implication of the work, including:

a. the strategy to get work done

b. constraints that get in the way

c. the structure of the physical environment as it supports work

d. the way work is divided

e. recurring patterns of activity

f. the implications the above has on any potential system

• Both customer and designer learn during this process; the customer learns what may be
possible and the designer expands his understanding of the work.
• Requirements modeling involves the techniques needed to express requirements in a way that
can capture user needs.

• There are a number of ways to model software requirements; these include natural languages,
informal and semiformal techniques, user stories, use case diagrams, structured diagrams,
object-oriented techniques, formal methods, and more.

• English, or any other natural language, have many problems for requirements communication.

• These problems include lack of clarity and precision, mixing of functional and non-functional
requirements, ambiguity, overflexibility, and lack of modularization.

• Every clear SRS must have a great deal of narrative in clear and concise natural language. But
when it comes to expressing complex behaviour, it is best to use formal or semiformal methods,
clear diagrams or tables, and narrative as needed to tie these elements together.
 Use Cases
• A use case is a description of how a user interacts with a system or product.

• Use cases are an essential artifact in object-oriented requirements elicitation and

analysis and are described graphically using any of several techniques.

• Artifact – something observed in a scientific investigation or experiment that is

not naturally present but occurs as a result of the preparative or investigative
procedure.

• One representation for the use case is the use case diagram, which depicts the
interactions of the software system with its external environment.
In a use case diagram, the box
represents the system itself.
The stick figures represent “actors” that
designate external entities that interact
with the system.
The actors can be humans, other
systems, or device inputs.
Internal ellipses represent each activity
of use for each of the actors (use cases).
The solid lines associate actors with
each use.
• Each use case is a document that describes scenarios of operation of the
system under consideration as well as pre and post conditions and
exceptions.

• In an iterative development life cycle, these use cases will become

increasingly refined and detailed as the analysis and design workflows
progress.
 User Stories
• User stories are short conversational texts that are used for initial requirements
discovery and project planning.

• User stories are widely used in conjunction with agile methodologies.

• User stories are written by the customers in their own “voice,” in terms of what
the system needs to do for them.

• User stories usually consist of two to four sentences written by the customer in
his own terminology, usually on a three-by-five inch card.
• The appropriate amount of user stories for one system increment or evolution is about
80, but the appropriate number will vary widely depending upon the application size
and scope

• User stories should provide only enough detail to make a reasonably low risk estimate
of how long the story will take to implement.

• When the time comes to implement the story, developers will meet with the customer
to flush out the details.

• User stories also form the basis of acceptance testing.

• For example, one or more automated acceptance tests can be created to verify the
user story has been correctly implemented.
 User Stories Examples
• “As a [user persona], I [want to], [so that].”

• Breaking this down:

• "As a [user persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person.
Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We
understand how that person works, how they think and what they feel. We have empathy for Max.

• “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve?
This statement should be implementation free

• “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit
they’re trying to achieve?

• For example, user stories might look like:

• As Max, I want to organize my work, so I can feel more in control.

• As a manager, I want to be able to understand my colleagues progress, so I can better report our sucess and
failures.
 User Stories in Scrum
• In Scrum, features are written from the end-user perspective as user stories

• The Key Roles in a Scrum framework: Product Owner, Scrum Master and Team

• Artifacts or Documents: Product Backlogs(user stories collection), Sprint Backlogs, and

Burndown Chart(progress of project)

• In the implementation of Agile, process is broken down into smaller pieces

• Plan Build Test Review Potentially Shippable Product

• Thus we have several incremental releases, or short duration milestones called Sprints

• Sprint Workflow: Product backlog Sprint Planning Sprint Backlog SPRINT

Potentially shippable product Sprint review Retrospective
 Requirements Documentation
• The SRS document is the official statement of what is required of the system
developers.

• The SRS should include both a definition and a specification of requirements.

• SRS is not a design document. It should be a set of what the system should do rather
than how it should do it.

• A variety of stakeholders uses the software requirements throughout the software life
cycle.
• Stakeholders include customers (these might be external customers
or internal customers such as the marketing department), managers,
developers, testers, and those who maintain the system.

• Each stakeholder has a different perspective on and use for the SRS.
• Requirements traceability is concerned with the relationships between
requirements, their sources, and the system design.

• During the requirements engineering process, the requirements must be

identified to assist in planning for the many changes that will occur throughout
the software life cycle.

• Requirements engineering is the process of eliciting, documenting, analyzing,

validating, and managing requirements.

• Traceability is also an important factor in conducting an impact analysis to

determine the effort needed to make such changes.
 Characteristics of good requirements

Clear

• Good requirements are clear, concise, and easy to understand.

• That means they can’t be pumped full of management‐speak, and confusing jargon.

• It is okay to use technical terms and abbreviations if they are defined some where or
they are common knowledge in the project's domain.

• In short, requirements cannot be vague or ill‐defined.

• Each requirement must state in concrete

Unambiguous

• A requirement must be unambiguous.

• If the requirement is worded so that we can’t tell what it requires, then we can’t build a
system to satisfy it.

• Although this may seem like an obvious feature of any good requirement, it’s
sometimes harder to guarantee than we might think.

• As we write requirements, do our best to make them unambiguous.

• Read them carefully to make sure we can’t think of any way to interpret them other
than the way we intend.
Consistent

• A project’s requirements must be consistent with each other.

• That means not only that they cannot contradict each other, but
that they also don’t provide so many constraints that the
problem is unsolvable.

• Each requirement must also be self‐consistent.(In other words,

it must be possible to achieve.)
Prioritized

• When we start working on the project’s schedule, it’s likely we need to

cut a few nice‐to‐haves from the design.

• We might like to include every feature but don’t have the time or
budget, so something’s got to go.

• At this point, we need to prioritize the requirements.

• If we have assigned costs (usually in terms of time to implement) and

priorities to the requirements, then we can defer the high‐cost,
low‐priority requirements until a later release.
Verifiable

• Requirements must be verifiable.

• If we can’t verify a requirement, how do we know whether we have

met it?

• Being verifiable means the requirements must be limited and precisely

defined.
The characteristics of good requirements. They are as follows:

• Correct — The SRS should correctly describe the system behavior.

• Unambiguous — An unambiguous SRS is one that is clear and not subject to different interpretations. Using
appropriate language can help avoid ambiguity.

• Complete — An SRS is complete if it completely describes the desired behavior.

• Consistent — One requirement must not contradict another

• Ranked — An SRS must be ranked for importance and/or stability. Not every requirement is as critical as another.
By ranking the requirements, designers will find guidance in making tradeoff decisions.

• Verifiable — Any requirement that cannot be verified is a requirement that cannot be shown to have been met.

• Modifiable — The requirements need to be written in such a way so as to be easy to change.

• Traceable — The SRS must be traceable because the requirements provide the starting point for the traceability
chain.
 REQUIREMENT CATEGORIES

Audience‐Oriented Requirements:

• These categories focus on different audiences and the different points of view that each
audience has.

• They use a somewhat business‐oriented perspective to classify requirements according

to the people who care the most about them.

Business Requirements:

• Business requirements layout the project’s high‐level goals. They explain what the
customer hopes to achieve with the project.
User Requirements:

• User requirements (which are also called stake holder requirements), describe how
the project will be used by the end users.

• They often include things like sketches of forms, scripts that’s how the steps users
will perform to accomplish specific tasks, use cases, and prototypes.

Functional Requirements:

• Functional requirements are detailed statements of the project’s desired capabilities.

• They are similar to the user requirements but they may also include things that the
users won’t see directly.
Non-functional Requirements:

• Non-functional requirements are statements about the quality of the application’s

behavior or constraints on how it produces a desired result.

• They specify things such as the application’s performance, reliability, and security
characteristics.

Implementation Requirements:

• Implementation requirements are temporary features that are needed to transition to

using the new system but that will be later discarded.

• After we finish testing the system and are ready to use it full time, you need a method to
copy any pending invoices from the old database into the new one.
 GATHERING REQUIREMENTS

• Listen to Customers (and Users):

• Start by listening to the customers.

• Learn as much as we can, about the problem they are trying to address and any ideas.

• Brain Storming – is a group activity exercise which helps to develop creative

solutions.

• Use the Five Ws (and One H):

• Who : ask who will be using the software and get to know as much as we can about
those people
• What :- Figure out what the customers need the application to do.
• When :- Find out when the application is needed.
• Where :- Find out where the application will be used. Will it be used on
desktop computers in an air-conditioned office? Or will it be used on phones
in a noisy subway?
• Why :- Ask why the customers need the application. Use the “why” question
to help clarify the customers’ needs and see if it is real.
• How :-We shouldn’t completely ignore the customers’ ideas. Sometimes,
customers have good ideas
 WRITING AN SRS DOCUMENT
• A Software Requirements Specification (SRS) is a document that describes the nature of a
project, software or application.
• In simple words, an SRS document is a manual of a project provided it is prepared before you
kick-start a project/application.
• This document is also known by the names SRS report, or software document.
• A software document is primarily prepared for a project, software, or any kind of application.
• There are a set of guidelines to be followed while preparing the software requirement
specification document.
• This includes the purpose, scope, functional and non-functional requirements, and software
and hardware requirements of the project.
• In addition to this, it also contains information about environmental conditions required,
safety and security requirements, software quality attributes of the project, etc.
 How to Write an SRS Document
• Creating a clear and effective SRS document can be difficult and time-consuming. But it is critical to the efficient development of a high quality
product that meets the needs of business users.
• Here are five steps you can follow to write an effective SRS document.

• 1. Define the Purpose With an Outline (Or Use an SRS Template)

• Your first step is to create an outline for your software requirements specification. This may be something you create yourself, or you can use an
existing SRS template.
• If you’re creating the outline yourself, here’s what it might look like:
• 1. Introduction
• 1.1 Purpose
• 1.2 Intended Audience
• 1.3 Intended Use
• 1.4 Product Scope
• 1.5 Definitions and Acronyms
• 2. Overall Description
• 2.1 User Needs
• 2.2 Assumptions and Dependencies
 How to Write an SRS Document
• 3. System Features and Requirements
• 3.1 Functional Requirements
• 3.2 External Interface Requirements
• 3.3 System Features
• 3.4 Nonfunctional Requirements
• This is a basic outline and yours may contain more (or fewer) items. Now that you have an outline, lets fill in the blanks.

• 2. Define your Product’s Purpose

• This introduction is very important as it sets expectations that we will come back to throughout the SRS.
• Some items to keep in mind when defining this purpose include:
• Intended Audience and Intended Use
• Define who in your organization will have access to the SRS and how they should use it. This may include developers, testers, and project managers. It could also
include stakeholders in other departments, including leadership teams, sales, and marketing. Defining this now will lead to less work in the future.
• Product Scope
• What are the benefits, objectives, and goals we intend to have for this product? This should relate to overall business goals, especially if teams outside of development
will have access to the SRS.
• Definitions and Acronyms
• Clearly define all key terms, acronyms, and abbreviations used in the SRS. This will help eliminate any ambiguity and ensure that all parties can easily understand the
document.
• If your project contains a large quantity of industry-specific or ambiguous terminology or acronyms, you may want to consider including a reference to a project
glossary, to be appended to the SRS, in this section.
 How to Write an SRS Document
• 3. Describe What You Will Build
• Your next step is to give a description of what you’re going to build. Why is this product needed? Who is it for? Is it a new product? Is it an add-on to a
product you’ve already created? Is this going to integrate with another product?

• Understanding and getting your team aligned on the answers to these questions on the front end makes creating the product much easier and more
efficient for everyone involved.

• User Needs

• Describe who will use the product and how. Understanding the various users of the product and their needs is a critical part of the SRS writing process.

• Who will be using the product? Are they a primary or secondary user? What is their role within their organization? What need does the product need to
fulfill for them?

• Do you need to know about the purchaser of the product as well as the end user? For the development of medical devices and med device software, you
may also need to know the needs of the patient.

• Assumptions and Dependencies

• What are we assuming will be true? Understating and laying out these assumptions ahead of time will help with headaches later. Are we assuming
current technology? Are we basing this on a Windows framework? We need to take stock of these technical assumptions to better understand where our
product might fail or not operate perfectly.

• Finally, you should note if your project is dependent on any external factors. Are we reusing a bit of software from a previous project? This new project
would then depend on that operating correctly and should be included.
 How to Write an SRS Document
• 4. Detail Your Specific Requirements
• In order for your development team to meet the requirements properly, we must include as much detail as possible.
This can feel overwhelming but becomes easier as you break down your requirements into categories. Some common
categories are functional requirements, interface requirements, system features, and various types of nonfunctional
requirements:

• Functional Requirements
• Functional requirements are essential to your product because, as the name implies, they provide some sort of
functionality.
• Asking yourself questions such as “does this add to my tool’s functionality?” or “what function does this provide?”
can help with this process. Within medical devices especially, these functional requirements may have a subset of
domain-specific requirements.
• You may also have requirements that outline how your software will interact with other tools, which brings us to
external interface requirements.
 How to Write an SRS Document
• External Interface Requirements
• External interface requirements are specific types of functional requirements. These
are especially important when working with embedded systems. They outline how
your product will interface with other components.
• There are several types of interfaces you may have requirements for, including:
• User
• Hardware
• Software
• Communications
• System Features
• System features are a type of functional requirements. These are features that are
required in order for a system to function.
 How to Write an SRS Document
• Non-functional Requirements
• Nonfunctional requirements, which help ensure that a product will work the way users and other stakeholders expect it to,
can be just as important as functional ones.
• These may include:
• Performance requirements
• Safety requirements
• Security requirements
• Usability requirements
• Scalability requirements
• The importance of each of these types of nonfunctional requirements may vary depending on your industry. In industries
such as medical device, life sciences, and automotive, there are often regulations that require the tracking and accounting of
safety.

• 5. Deliver for Approval

• We made it! After completing the SRS, you’ll need to get it approved by key stakeholders. This will require everyone to
review the latest version of the document.