Chapter 1

Software Requirement Engineering

Introduction
Done well, requirements engineering presents an opportunity to reduce costs and increase
the quality of software systems. Done poorly, it could lead to a software project failure.
So it’s no surprise that there has been much interest in software requirements engineering
over the past 10 years or so. Many software project failures have been attributed to
requirements engineering issues. These include poorly documented requirements,
requirements that were impossible to satisfy, requirements that failed to meet the needs of
users, and requirements creep--the gradual inclusion of unanticipated, undocumented, and
poorly considered requirements.
Even when projects do not fail outright, software developers now recognize that errors
that occurs early in the development life cycle, particularly at the requirements stage, turn
out to be the most difficult and costly to fix. This is especially true when the errors are not
discovered until late in the life cycle--perhaps at implementation.
The relatively recent attention to requirements engineering is fairly typical of the patterns
seen in earlier advances in software engineering. Software engineers initially focused on
programming methods, then on design methods, and are now focusing on requirements
methods, in an attempt to introduce more discipline in the software engineering process.
In the early days, requirements were developed in English text, but over time have
evolved into structured and in some cases formal specifications.
More recently there has been interest in requirements elicitation, because working with
non-technical people can be among the most challenging areas of software development.
In an effort to communicate with non-technical customers and understand their needs,
software developers have teamed with experts from the social sciences to gain new
perspectives on solving the thorny communication problems that can plague an
acquisition effort.
Systematic requirements analysis is also known as requirements engineering. It is
sometimes referred to loosely by names such as requirements gathering, requirements capture, or

1
requirements specification. The term requirements analysis can also be applied specifically to the
analysis proper, as opposed to elicitation or documentation of the requirements, for instance.

Requirements describe
“WHAT” of a system not “HOW”
Requirement engineering is a sub discipline of software engineering that is concerned with
determining the goals, functions, and constrains of software systems. Ideally the requirement
engineering process begins with a feasibility study activity, which leads to a feasibility report. If
the feasibility study suggested that the product should be developed, then requirement analysis
can begin. If requirement analysis precedes feasibility studies, which may foster outside the box
thinking, then feasibility should be determined before requirements are finalized.

Crucial Process Steps

The quality of a software product is only as good as the process that creates it.
Without well written document:-
-- Developers do not know what to build
-- Customers do not know what to expect
-- What to validate nizations

2
Present State of Practice
Most software development organizations agree to fact that there should be a set of activities
called requirement engineering and their success is vital to the success of the entire project.
There are some problems:-
1. Requirements are difficult to uncover
2. Requirements change
3. Over reliance on CASE Tools
4. Tight project Schedule
5. Communication barriers
6. Market driven software development
7. Lack of resources

3
Requirements Engineering

R e q u i r e m e n t s E n g i n

R e q u ir e m e R n e t sq u E i r l ie c m i t a e t ni o t ns

R e q u i r e m eR n e t qs u S i r p e e m c e i f ni c t a s t

R e q u i r e m e n t s M a n a g e m

Type of Requirements

There are different types of requirements such as:

1) Known Requirements- Something a stakeholder believes to be implemented.
2) Unknown Requirements- Forgotten by the stakeholder because they are not needed
right now or needed only by another stakeholder.
3) Undreamt Requirements- Stakeholders may not be able to think of new requirements
due to limited domain knowledge.

Stakeholder: Anyone who should have some direct or indirect influence on the system
requirements. ”Stakeholders” includes end-users who will interact with the system and
everyone else in an organization who will be affected by it.

4
Functional and Non-Functional Requirements
Software requirements are broadly classified as functional and non-functional requirements.
Functional Requirement: - Statements of services the system should provide how
the system should react to particular inputs and how the system should behave in
particular situations. They describe what the software has to do. They are also called
product features. These are directly related to customer’s expectations and essential for
the acceptance of product.
It mainly describe:-
• Describe functionality or system services
• Depend on the type of software, expected users and the type of system where the
software is used.
• Functional user requirements may be high-level statements of what the system should
do but functional system requirements should describe the system services in detail.

Non-Functional Requirement: -Constraints on the services or functions offered by

the system such as timing constraints, constraints on the development process, standards,
etc. These are mostly quality requirement that stipulate how well the software does what
it has to do. Non-functional requirements for developers are maintainability, portability
and testability.
It mainly describe:-
• Define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
• Process requirements may also be specified mandating a particular system,
programming language or development method.
• Non-functional requirements may be more critical than functional requirements. If
these are not met, the system is useless.

Non-functional classifications
Product requirements
– Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
Organizational requirements
– Requirements which are a consequence of organizational policies and procedures e.g. process
standards used, implementation requirements, etc.

5
External requirements
– Requirements which arise from factors which are external to the system and its development
process e.g. interoperability requirements, legislative requirements, etc.

User and System Requirements

User requirements are written for the users and include functional and non-functional
requirements. Users may not be the experts of the software field; hence simple language should
be used. User requirements should specify the external behavior of the system with some
constraints and quality parameters. However, design issues should be avoided.
System requirements are derived from user requirements. They are expanded form of user
requirements. They may be used as input to the designers for the preparation of software design
document.

Interface Specification
Interfaces issues are very important for the customers. A good software may not be appreciated if
interfaces are not as per expectations of the customers. The types of interfaces are:
1. Procedural interfaces: -These are called Application Programming Interfaces
(APIs).
2. Data Structures: -Used to transfer information from one module to another module.
3. Representation of data: -The issues related to ordering of bits are established here.

Feasibility Studies
A feasibility study looks at the viability of an idea with an emphasis on identifying potential
problems and attempts to answer one main question: Will the idea work and should you proceed
with it?

Before you begin writing your business plan you need to identify how, where, and to whom you
intend to sell a service or product. You also need to assess your competition and figure out how
much money you need to start your business and keep it running until it is established.

Feasibility studies address things like where and how the business will operate. They provide in-
depth details about the business to determine if and how it can succeed, and serve as a valuable
tool for developing a winning business plan.

6
Why Are Feasibility Studies so Important?
The information you gather and present in your feasibility study will help you:

• List in detail all the things you need to make the business work;
• Identify logistical and other business-related problems and solutions;
• Develop marketing strategies to convince a bank or investor that your business is worth
considering as an investment; and
• Serve as a solid foundation for developing your business plan.

Even if you have a great business idea you still have to find a cost-effective way to market and
sell your products and services. This is especially important for store-front retail businesses
where location could make or break your business.

For example, most commercial space leases place restrictions on businesses that can have a
dramatic impact on income. A lease may limit business hours/days, parking spaces, restrict the
product or service you can offer, and in some cases, even limit the number of customers a
business can receive each day.

The Components of a Feasibility Study

• Description of the Business: The product or services to be offered and how they
will be delivered.
• Market Feasibility: Includes a description of the industry, current market, anticipated
future market potential, competition, sales projections, potential buyers, etc.
• Technical Feasibility: Details how you will deliver a product or service (i.e.,
materials, labor, transportation, where your business will be located, technology needed,
etc.).
• Financial Feasibility: Projects how much start-up capital is needed, sources of
capital, returns on investment, etc.
• Organizational Feasibility: Defines the legal and corporate structure of the
business (may also include professional background information about the founders and
what skills they can contribute to the business).

Purpose of feasibility studies

The purpose of a Feasibility Study is to identify the likelihood of one or more solutions
meeting the stated business requirements. In other words, if you are unsure whether your
solution will deliver the outcome you want, then a Project Feasibility Study will help gain

7
 that clarity. During the Feasibility Study, a variety of 'assessment' methods are undertaken.
The outcome of the Feasibility Study is a confirmed solution for implementation.

Focus of feasibility studies

Steve McConnell has given the following points on which a feasibility study should focus and
give proper emphasis to get good results:

• Is the concept viable?

• Will it be possible to develop a product that matches the project’s vision statement?
• What are the current estimated cost and schedule for the project?
• How big is the gap between the original cost and schedule targets and current estimates?
• Have the major risks to the project been identified and can they be surmounted?
• Is the software development plan complete and adequate to support further development
work?

The work done during the first 10-20 percent of the project should sufficiently answer these
questions and give the top management enough information to decide whether to fund the rest of
the project.

8
 Chapter 2

Requirements Elicitation
Requirement elicitation is perhaps most difficult, most critical, most error-prone, and most
communication intensive aspect of software development. Elicitation can succeed only through
an effective customer-developer partnership. Requirements elicitation comprises activities that
enable the understanding of the goals, objectives, and motives for building a proposed software
system. Elicitation also involves identifying the requirements that the resulting system must
satisfy in order to achieve these goals.

Selection of any method among number of methods of requirements elicitation.

1. It is the only method that we know.
2. It is our favorite method for all situations.
3. We understand intuitively that the method is effective in the present circumstances.
Normally we rely on first two reasons.

Interviews and Questionnaires

• Simple direct technique.

• Interview may be open-ended or structured.

• Context-free questions can help achieve bias-free interviews – See course web site for
examples.

• Then, it may be appropriate to search for undiscovered requirements by exploring

solutions.

• Convergence on some common needs will initiate a “requirements repository” for use
during the project.

• A questionnaire is no substitute for an interview.

Selection of stakeholder
9
 1. Entry level personnel
2. Middle level stakeholder
3. Managers
4. Users of the software (Most important)

Interview: Context free question

• Goal is to prevent prejudicing the user’s response to the questions.

• Examples:

• Who is the user?

• Who is the customer?

• Are their needs different?

• Where else can a solution to this problem be found?

• Context-free questions also parallel the questions salespeople are taught to ask as part of
a technique called “solutions selling.”

• After context-free questions are asked, suggested solutions can be explored.

Interview: Show time:

• Establish Customer or User Profile

• Assessing the Problem

• Understanding the User Environment

• Recap the Understanding

• Analyst’s Inputs on Customer’s Problems

• Assessing Your Solution (if applicable)

Brainstorming
• Brainstorming involves both idea generation and idea reduction.
• The most creative, innovative ideas often result from combining, seemingly unrelated
ideas.
• Various voting techniques may be used to prioritize the ideas created.
• Although live brainstorming is preferred, web-based brainstorming may be a viable
alternative in some situations

10
Rules for Brainstorming
• Do not allow criticism or debate.
• Let your imagination soar
• Generate as many ideas as possible
• Mutate and combine ideas
• Idea Reduction
– Pruning ideas that are not worthy of further discussion
– Grouping of similar ideas into one super topic
• Prioritize the remaining ideas

Facilitated Application specification Techniques (FAST)

• Similar to brainstorming sessions.
• Team oriented approach
• Creation of joint team of customers and developers.

Guidelines
1. Arrange a meeting at a neutral site.
2. Establish rules for participation.
3. Informal agenda to encourage free flow of ideas.
4. Appoint a facilitator.
5. Prepare definition mechanism board, worksheets, wall
6. stickier.
7. Participants should not criticize or debate.

Quality Function Deployment

• Incorporate voice of the customer. Prime concern is customer satisfaction.
The QFD method has the following steps: -
1. Identify stakeholders
2. List out requirements
3. Degree of importance to each requirement.

The Use Case Approach

Use Cases are structured outline or template for the description of user requirements modeled in
a structured language like English. Use case Scenarios are unstructured descriptions of user
requirements. Use case diagrams are graphical representations that may be decomposed into
further levels of abstraction.

11
A use case is a technique for documenting the potential requirements of a new system or
software change. Each use case provides one or more scenarios that convey how the system
should interact with the end user or another system to achieve a specific business goal. Use cases
are often co-authored by requirements engineers and stakeholders.
Use cases are deceptively simple tools for describing the behavior of software or systems. A use
case contains a textual description of all of the ways which the intended users could work with
the software or system. Use cases do not describe any internal workings of the system, nor do
they explain how that system will be implemented. They simply show the steps that a user
follows to perform a task. All the ways that users interact with a system can be described in this
manner.

Jacobson & others proposed a template for writing Use cases as shown below:

Flow of Events

12
 Chapter 3

Requirements Analysis
Requirements analysis in systems engineering and software engineering, encompasses
those tasks that go into determining the needs or conditions to meet for a new or altered product,
taking account of the possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must

be actionable, measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.

Requirements analysis, also called requirements engineering, is the process of determining user
expectations for a new or modified product. These features, called requirements, must be
quantifiable, relevant and detailed. In software engineering, such requirements are often called

13
functional specifications. Requirements analysis is an important aspect of project
management.

Requirements analysis is the first stage in the systems engineering process and software
development process.
Requirement analysis is concerned with the process of analyzing requirements to

* Detect and resolve conflicts between requirements

* Discover the bounds of the software and how it must interact with its environment
* Elaborate system requirements to derive software requirements

The traditional view of requirements analysis has been that it be reduced to conceptual modeling
using one of a number of analysis methods such as the Structured Analysis and Design
Technique (SADT). While conceptual modeling is important, we include the classification of
requirements to help inform trade-offs between requirements (requirements classification) and
the process of establishing these trade-offs (requirements negotiation).
Care must be taken to describe requirements precisely enough to enable the requirements to be
validated, their implementation to be verified, and their costs to be estimated.

Requirement analysis is hard

Major causes of project failures
•Poor user input
•Incomplete requirements
•Changing requirements

Difficulties
• Complex problems, unknown domains, nontechnical customers, communication-
intensive
Essential tools
• Classification of requirements

14
 • Use cases

Requirement analysis tasks

1. Problem Recognition: as perceived by the customer.
2. Evaluation & Synthesis: The analysts define data objects, evaluate the flow of
information, define all software functions, understand system behavior, establish system
interface characteristics and design constraints.
3. Modeling: models of data, information and control flow, and operational behaviors.
4. Specification: a model of the software is created and evaluated by both software engineers
and customers.
5. Review: of software requirements specifications done by developer and customer.

Analysis Principals
1. Information domain of a problem must be represented and understood
2. Required functions must be defined
3. Behavior of software must be represented
4. Models that depict information, function, and behavior must be partitioned in a layered or
hierarchical fashion
5. Analysis process should move from essential info to implementation detail.

Requirement analysis steps

1. Draw the context diagram: -The context diagram is a model that defines the
boundaries and interfaces of the proposed system with the external world. It identifies the
entities outside the proposed system that interact with the system.
2. Development of a prototype(optional): -One effective way to find out what the
customer
really wants is to construct a prototype, something that looks and preferably acts like a
part of the system they say they want. Some projects are developed for general market.
The prototype should be built quickly and a relatively low cost. hence it will always have
limitations and would not be acceptable in the final system.
3. Model the requirements: -The process usually consists of various graphical
representations of the functions, data entities, external entities and the relationship
between them. The graphical view may help to find incorrect, inconsistent, missing and
superfluous requirements. Such models include data flow diagrams, Entity relationship
diagrams, data dictionaries, state- transition diagrams etc.
4. Finalize the requirements: -After modeling the requirements, we will have better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected. Flow of data amongst various modules has been analyzed. Now
we finalized requirements and next step is to document these requirements in a prescribed
format.

15
 Analysis model elements
1 Data Dictionary
 Contains descriptions of all data objects used
2 Entity-Relationship Diagram (ERD)
 Describes relationships between data objects
3 Data Flow Diagram (DFD)
 Describes data flow & transformation
4 State Transition Diagram (STD)
 Describes system behavior

Data flow diagrams

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system. DFDs can also be used for the visualization of data processing (structured
design).

On a DFD, data items flow from an external data source or an internal data store to an internal
data store or an external data sink, via an internal process.

16
A DFD provides no information about the timing or ordering of processes, or about whether
processes will operate in sequence or in parallel. It is therefore quite different from a flowchart,
which shows the flow of control through an algorithm, allowing a reader to determine what
operations will be performed, in what order, and under what circumstances, but not what kinds
of data will be input to and output from the system, nor where the data will come from and go to,
nor where the data will be stored (all of which are shown on a DFD).

There are only five symbols that are used in the drawing of business process diagrams
(dataflow diagrams). These are now explained, together with the rules that apply to them.

This diagram represents a banking process, which maintains customer accounts. In this
example, customers can withdraw or deposit cash, request information about their account or
update their account details. The five different symbols used in this example represent the
full set of symbols required to draw any business process diagram.

External Entity:-

An external entity is a source or destination of a data flow which is outside the area of
study. Only those entities which originate or receive data are represented on a business
process diagram. The symbol used is an oval containing a meaningful and unique
identifier.

17
Process

A process shows a transformation or manipulation of data flows within the system. The
symbol used is a rectangular box which contains 3 descriptive elements:
Firstly an identification number appears in the upper left hand corner. This is allocated
arbitrarily at the top level and serves as a unique reference.
Secondly, a location appears to the right of the identifier and describes where in the
system the process takes place. This may, for example, be a department or a piece of
hardware. Finally, a descriptive title is placed in the centre of the box. This should be a
simple imperative sentence with a specific verb, for example 'maintain customer records'
or 'find driver'.

Data Flow

A data flow shows the flow of information from its source to its destination. A data flow
is represented by a line, with arrowheads showing the direction of flow. Information
always flows to or from a process and may be written, verbal or electronic. Each data
flow may be referenced by the processes or data stores at its head and tail, or by a
description of its contents.

Data Store

18
 A data store is a holding place for information within the system:
It is represented by an open ended narrow rectangle.
Data stores may be long-term files such as sales ledgers, or may be short-term accumulations:
for example batches of documents that are waiting to be processed. Each data store should be
given a reference followed by an arbitrary number.

Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For
this reason they are sometimes referred to as physical flows.
The physical material in question should be given a meaningful name. Resource flows are
usually restricted to early, high-level diagrams and are used when a description of the physical
flow of materials is considered to be important to help the analysis.

Data dictionaries
Data dictionaries are simply repositories to store information about all data items defined in
DFDs. As the requirements stage, the data dictionary should at least define customer data items,
to ensure that the customer and developer use the same definitions and terminologies. Typical
information stored includes:

• Name of the data item

• Aliases (other names for item)
• Descriptions/purposes
• Related data items
• Range of values
• Data structure definition/form

The name of the data item is self explanatory. Aliases include other names by which this data
item is called e.g., DEO for data entry operator and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is used for or why it exists.
Related data item capture relationship between data items capture relationships between data
items.
The data dictionary can be used to:
• Create on ordered listing of all data items.

• Create an ordered listing of a subset of data items.

19
 • Find a data item name from a description.

• Design the software and test cases.

Entity relationship diagrams

In software engineering, an Entity-Relationship Model (ERM) is an abstract and conceptual
representation of data. Entity-relationship modeling is a database modeling method, used to
produce a type of conceptual schema or semantic data model of a system, often a relational
database, and its requirements in a top-down fashion.
Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or
ERDs for short.

There are three basic elements in ER models:

Entities are the "things" about which we seek information.

Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw information from multiple entities.

Entities

An entity is a fundamental thing of an organization about which data may be maintained.

An entity has its own identity, which distinguishes it from each other entity. An
entity type is the description of all entities to which a common definition and
common definition and common relationship and attributes apply.

An entity is a real-world item or concept that exists on its own. In our example, a particular
student (such as, "Emanuel Vagas"), team, lab section, or experiment is an entity.
The set of all possible values for an entity, such as all possible students, is the entity
type. In an ER model, we diagram an entity type as a rectangle containing the type
name, such as student

Definition An entity is a real-world item or concept that exists on its own. The set
of all possible values for an entity is the entity type.

ER diagram notation for entity student

20
Attributes
Each entity has attributes, or particular properties that describe the entity. For example,
student Emanuel Vagas has properties of his own Student Identification number,
name, and grade. A particular value of an attribute, such as 93 for the grade, is a
value of the attribute. Most of the data in a database consists of values of attributes.
The set of all possible values of an attribute, such as integers from 0 to 100 for a
grade, is the attribute domain. In an ER model, an attribute name appears in an
oval that has a line to the corresponding entity box, such as in Figure 3.

Definition An attribute of an entity is a particular property that describes the

entity. The set of all possible values of an attribute is the
attribute domain.

Figure 3. ER diagram notation for an attribute domain (StudentGrade) of an entity

type (student)

Relationship
A relationship type is a set of associations among entity types. For example, the student entity
type is related to the team entity type because each student is a member of a team. In this case, a
relationship or relationship instance is an ordered pair of a specific student and the student's
particular physics team, such as (Emanuel Vagas, Phys201F2005A04), where
Phys201F2005A04 is Emanuel's team number. Figure 8 illustrates three relationships.
Unfortunately, Itnatios Trekas had to drop the course and retake it another semester.
Consequently, his name is associated with two team numbers.

21
We use a diamond to illustrate the relationship type in an ER diagram, such as in Figure 9.
We arrange the diagram so that the relationship reads from left to right, "a student is a
member of a team." Alternatively, we can arrange the components from top to bottom.

Definition A relationship type is a set of associations among entity types. A

relationship or relationship instance is an ordered pair consisting of
particular related entities.

Figure 9. ER diagram notation for relationship type, MemberOf

ER diagram looks like

22
Developing an ERD
Developing an ERD requires an understanding of the system and its components.

Consider a hospital:

Patients are treated in a single ward by the doctors assigned to them. Usually each patient
will be assigned a single doctor, but in rare cases they will have two.

Healthcare assistants also attend to the patients; a number of these are associated with each
ward.

Initially the system will be concerned solely with drug treatment. Each patient is required
to take a variety of drugs a certain number of times per day and for varying lengths
of time.

The system must record details concerning patient treatment and staff payment. Some staff
is paid part time and doctors and care assistants work varying amounts of overtime
at varying rates (subject to grade).

The system will also need to track what treatments are required for which patients and
when and it should be capable of calculating the cost of treatment per week for each
patient (though it is currently unclear to what use this information will be put).

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in the
discussion of business rules, or in documentation; identified in the narrative (see
highlighted items above).

2. Define Relationships: these are usually verbs used in descriptions of the system or in
discussion of the business rules (entity ______ entity); identified in the narrative.

3. Add attributes to the relations: these are determined by the queries, and may also
suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask?

Which doctors work in which wards?

How much will be spent in a ward in a given week?
How much will a patient cost to treat?
How much does a doctor cost per week?
Which assistants can a patient expect to see?
Which drugs are being used?

23
4. Add cardinality to the relations

Many-to-Many must be resolved to two one-to-many with an additional entity

Usually automatically happens

Sometimes involves introduction of a link entity (which will be all foreign key) Examples:
Patient-Drug

5. This flexibility allows us to consider a variety of questions such as:

a. Which beds are free?

b. Which assistants work for Dr. X?

c. What is the least expensive prescription?

d. How many doctors are there in the hospital?

e. Which patients are family related?

Reading an ERD
It takes some practice reading an ERD, but they can be used with clients to discuss business
rules.

These allow us to represent the information from above such as the E-R Diagram below:

24
There are three types of relationships between entities:

One-to-One: one instance of an entity (A) is associated with one other instance of another
entity (B). For example, in a database of employees, each employee name (A) is
associated with only one social security number (B). One-to-one relationships

 One-to-Many: one instance of an entity (A) is associated with zero, one or many
instances of another entity (B), but for one instance of entity B there is only one instance
of entity A. For example, for a company with all employees working in one building,
the building name (A) is associated with many different employees (B), but those
employees all share the same singular association with entity A.

 Many-to-many: one instance of an entity (A) is associated with one, zero or many
instances of another entity (B), and one instance of entity B is associated with one, zero
or many instances of entity A. For example, for a company in which all of its employees
work on multiple projects, each instance of an employee (A) is associated with many
instances of a project (B), and at the same time, each instance of a project (B) has
multiple employees (A) associated with it.

Software Prototyping
A prototype is a working model of one or more aspects of the project system. It is constructed
and tested quickly and inexpensively in order to test out assumptions.
Two most popular prototyping approaches: -
Throw-away prototypes: -Here the prototype is used only to test out some ideas and is then
discarded when the true development of the operational system is commenced. The prototype
could be developed using a different software environment or even on a different kind of
hardware platform.

25
Evolutionary prototypes: -The prototype is developed and modified until it is finally in a
state where it can become the operational system. In this case the standards that are used to
develop the software have to be carefully considered.

Requirements Documentation
• Requirements documentation is very important activity after the requirements elicitation
and analysis. This is the way to represent requirements in a consistent format.
Requirements documentation is called Software Requirements Specification (SRS).
• The requirements document is the official statement of what is required of the system
developers.
• Should include both a definition and a specification of requirements.
• It is NOT a design document. As far as possible, it should set of WHAT the system
should do rather than HOW it should do it.
• The SRS is a specification for a particular software product, program or set of programs
that performs certain functions in a specific environment. It serves a number of purposes
depending on who is writing it.
• First, the SRS could be written by the customer of a system. It is used to define
the needs and expectations of the customers.
• Second, the SRS could be written by a developer of the system. In this SRS is
written for different purpose and serve as a contract document between customer
and developer.

Nature of the SRS

The basic issues that SRS writer(s) shall address are the following:
1. Functionality: What the software is supposed to do?
2. External interfaces: How does the software interact with people, the system’s
hardware, other hardware, and other software?
3. Performance: What is the speed, availability, response time, recovery time, etc. of
various software functions?
4. Attributes: What are the considerations for portability, correctness, maintainability,
security, reliability, etc.?
5. Design constraints imposed on an implementation: Are there any required
standards in effect, implementation language, policies for database integrity, resource
limits, operating environment(s), etc.?

26
Since the SRS has a specific role to play in the software development process, SRS writer(s)
should be careful not to go beyond the bounds of that role. This means the SRS
1. Should correctly define all the software requirements. A software requirement may exist
because of the nature of the task to be solved or because of a special characteristic of the
project.
2. Should not describe any design or implementation details. These should be described in
the design stage of the project.
3. Should not impose additional constraints on the software. These are properly specified in
other documents such as a software quality assurance plan.

Characteristics of a good SRS

The skill of writing a good SRS document usually comes from the experience gained from
writing similar documents for many problems. However, the analyst should be aware of the
desirable qualities that every good SRS document should possess. Some of the identified
desirable qualities of the SRS documents are the following:
1. Concise: -The SRS document should be concise and at the same time unambiguous,
consistent, and complete. Verbose and irrelevant descriptions reduce readability and also
increase error possibilities.
Unambiguous: -An SRS is unambiguous if and only if, every requirement stated
therein has only one interpretation.
Consistent: -An SRS is consistent if and only if, no subset of individual requirements
described in it conflict.
Complete: -An SRS is complete if and only if, it includes the following elements:-
a. All significant requirements, whether related to functionality, performance, design
constraints, attributes or external interfaces.
b. Responses to both valid & invalid inputs.
c. Full Label and references to all figures, tables and diagrams in the SRS and
definition of all terms and units of measure.
2. Structured: -The SRS document should be well-structured. A well-structured
document is easy to understand and modify. In practices, the SRS document undergoes
several revisions to cope with the customer requirements. Often, the customer
requirements evolve over a period of time. Therefore, in order to make the modifications
to the SRS document easy, it is important to make the document well-structured.
3. Black-box view: -It should only specify what the system should do and refrain from
stating how to do. This means that the SRS document should specify the external
behavior of the system and not discuss the implementation issues. It should view the
system to be developed as a black box, and should specify the externally visible behavior
of the system. For this reason, the SRS document is also called the black-box
specification of a system.

27
 4. Conceptual integrity: -The SRS document should exhibit conceptual integrity so
that the reader can easily understand the contents.
5. Response to undesired events: -The document should characterize acceptable
responses to undesired events. These are called system responses to exceptional
conditions.
6. Verifiable: -All requirements of the system as documented in the SRS document
should be verifiable. This means that it should be possible to determine whether or not
requirements have been met in an implementation. Requirements such as ‘the system
should be user friendly’ are not verifiable.
7. Traceable: - It means that it would be possible to tell which design components
corresponds to which requirement, which code corresponds to which design component,
and which test case corresponds to which requirements, etc. Two types of traceability are
recommended.
a. Backward Traceability: -This depends upon each requirement explicitly
referencing its source in earlier documents. It is especially important when the
software product enters the operation and maintenance phase.
b. Forward Traceability: -This depends upon each requirement in the SRS
having a unique name or reference number.

Organization of the SRS

The Institute of Electricals and Electronics Engineers (IEEE) has published guidelines and
standards to organize an SRS documentIEEE87, IEEE94]. Different projects may require their
requirements to be organized differently, that is no one method that is suitable for all projects.
The general organization of an SRS is as follows [IEEE93].
1. Introduction
1) Purpose: -Identify the purpose of this SRS and its intended audience.
2) Scope: -
a. Identify the software product(s) to be produced by name.
b. Explain what the software product(s) will, and if necessary, will not do.
c. Describe the application of the software being specified, including relevant benefits,
objectives, and goals.
d. Be consistent with similar statements in higher-level specifications if they exist.
3) Definitions, Acronyms, and Abbreviations: -Provide the definitions of all terms,
acronyms, and abbreviations required to properly interpret the SRS.
4) References: -
a. Provide a complete list of all documents referenced elsewhere in the SRS.

28
 b. Identify each document by title, report number (if applicable), date and publishing
organization.
c. Specify the sources from which the references can be obtained.
5) Overview: -
a. Describe what the rest of the SRS contains.
b. Explain how the SRS is organized.

2. The Overall Description: -Describe the general factors that affect the product and its
requirements. It provides a background for those requirements, which are defined and make them
easier to understand.
1) Product Perspective: -Put the product into perspective with other related products. If the
product is independent and totally self-contained, it should be so stated here. If the SRS
defines a product that is a component of a larger system, as frequently occurs, then this
relates to the requirements of the larger system to functionality of the software and
identifies interfaces between that system and software.
2) Product Functions: -Provide a summary of the major functions that the software will
perform. Sometimes the function summary that is necessary for this part can be taken
from the section of higher-level specification (if one exists) that allocates particular
functions to the software product.
3) User Characteristics: -Describe those general characteristics of the intended users of the
product including educational level, experience, and technical expertise. Do not state
specific requirements.
4) Constraints: -Provide a general characteristic of any other items that will limit the
developer’s options. These can include regulatory policies, interface to other applications,
parallel operation, audit functions, control functions, reliability requirements, etc.
5) Assumptions and Dependencies: -List of factors that affect the requirements stated in
the SRS. These factors are not design constraints on the software but are, rather any
changes to them that can affect the requirements in the SRS.
6) Apportioning of Requirements: -Identify requirements that may be delayed until future
versions of the system.

3. Specific Requirements
1) External Interfaces: -This contains a detailed description of all inputs into and outputs
from the software system. It complements the interface description.
2) Functions: -Functional requirement define the fundamental actions that must take place
in the software in accepting and processing the inputs and in processing and generating
the output.

29
 3) Performance Requirements: -This specifies both static and dynamic numerical
requirements placed on the software or on human interaction with the software, as a
whole.
4) Logical Database Requirements: -This specifies the logical requirements for any
information that is to be placed into a database.
5) Design Constraints: -Specify design constraints that can be imposed by other standards,
hardware limitations, etc.
6) Software System Attributes: -There are number of quality attributes of software that can
serve as requirements. Some of them are reliability, security, availability, maintainability
and portability.
7) Organizing the Specific Requirements: -For anything but trivial systems the detailed
requirements tend to be extensive. Some of these organizations are described as user
class, objects, features, stimulus, response and functional hierarchy.

4. Change Management Process: -Identify the change management process to be used to

identify, log, evaluate, and update the SRS to reflect changes in project scope and requirements.

5. Document Approval: -Identify the approvers of the SRS document. Approver’s name,
signature, and date should be used.

6. Supporting Information: -It makes SRS easier to use. It includes: -

• Table of Contents
• Index
• Appendices

Requirements Validation
Check that our requirements definitions accurately reflect all of the stakeholders’ needs
(i.e., we build the system right).
The objective of requirements validation is to certify that the SRS document is an acceptable
document of the system to be implemented. This helps us to find errors in the document and
improves the quality of the software development process. Sometimes we confuse between
analysis and validation. However, analysis works with raw requirements as elicited from the
various stakeholders whereas validation works with a final draft of the SRS document with
negotiated and agreed requirements.
There are many requirement validation techniques

30
SRS document: -It should be a final draft, not an unfinished draft and should be
formatted/organized as per IEEE standards.
Organizational standards: -Every organization should have some quality standards for
SRS document and other activities. These standards will be used for reviewing during validation.
Organizational knowledge: -Knowledge, often implicit, of the organization which may be
used to judge the realism of the requirements.
Problem list: -List of discovered problems in the requirements document.
Approved actions: -List of approved actions in response to the requirements problems.

Requirements reviews
This is a popular requirements validation technique where a group of people will read the
SRS document and look for possible problems. These identified problems may be discussed
in the group and some actions may also be approved in order to get rid of these problems.
The requirements review processes are:-
1. Plan review: -The review team is selected and time and place for review meeting is
fixed.
2. Distribute SRS document: -The SRS document is distributed to all the members.
3. Read SRS document: -Each member should read the document carefully to find
conflicts, omissions, inconsistencies, deviations from standards and other problems.
4. Organize review meeting: -Each member presents his/her views and identified
problems. The problems are discussed and set of actions to address the problem is
approved.
5. Follow-up actions: - The chairperson of the team checks the approved actions have
been carried out.
6. Revise SRS document:-The SRS document is revised to reflect the approved
actions. At this stage, it may be accepted or may be reviewed.

Desirable Characteristics in Review Checklist

Are the Requirements correct?
• Ensure common understanding with the customer/stakeholders of the requirements
definitions.
Are the requirements consistent?
• Ensure there are no conflicting requirements.

31
Are the requirements unambiguous?
• Multiple readers (reviewers) of the document should not walk away with different but
valid interpretations of the document
Are the requirements complete?
• The requirements is considered to be specifies required behavior and output for all
possible inputs in all possible states.
Are the requirements feasible?
• Does a solution to the customer needs exist?
Is every requirement relevant?
• Check if the requirements include functions that are unrelated to the customers’ needs.
Are the requirements testable?
Are the requirements traceable?
• Requirements are organized and uniquely labeled (enumerated) for reference. Every entry
in the requirements definition has a corresponding entry in the requirements specification,
and vice versa.

Requirement Management
Requirement management is a new term which has been rapidly adopted by industry. It is a
process of understanding and controlling changes to system requirements. Most of the times,
requirements are not independent; but are dependent on each other. Hence, one change may have
implications on other requirements and thus make the task much more difficult and challenging.
Enduring and Volatile Requirements
i. Enduring Requirements: -These are core requirements and are related to main
activity of the organization. For a library management system, issue/return a book,
cataloging etc. are core activities and are stable for any system. Hence, enduring
requirements are stable and are not changed easily.

ii. Volatile requirements: -These requirements are likely to change during software
development life cycle or even after delivery of the product. There are many reasons for
such changes some of the reasons are:

• Changes to the environment

• Changes in technology

• Changes in policies

32
 • Changes in customer’s expectations

Requirements Management Planning

Requirement management planning is very critical, but important for the success of any project.
The process of requirement management ends when the final product is released, and the
customer is fully satisfied. However, the fewer modifications, may also be better for everybody.
Tracing requirements also involves additional tests, performed from time to time, to ensure that
the process runs smoothly and errors are identified and correctly early on. When faced with a big
project, we may have different sets of requirements, some that apply to the entire project, and
some for parts of it. When a certain design is implemented for certain requirements, make a note
about the effects and the alternatives it may be useful for future project or even for the same
project, if the customer is not satisfied with the result.

Requirements Change Management

The customers expect modern software to be evolved and sufficiently flexible to accommodate
changing user’s needs. This expectation, however, is untempered by the fact that changing
requirements are recognized as a major cause of project failure. This may also have a degrading
effect on the underlying design of a system. The fact of life is that software requirements change
and evolve from inception of deployment.
Hence changes to requirements are carefully traced, analyzed and their effects on the overall
system are properly assessed. The requirements change process should include the following
activities to be carried out when a change is needed in the requirements
• Allocating adequate resources (Assignment of Responsibilities).

• Analysis of requirement changes (Management of Changes).

• Documenting requirements (Documentation).

• Creating requirements traces throughout the project life cycle from inception to
the final work products (Requirements traceability).

• Establishing team communication (communication of change).

• Establishing a baseline for requirements specification (establishment of baseline).

I. Assignment of responsibilities: - All changes should be approved or rejected by

the competent authority for the project. It may be project manager, project lead or may
other equivalent person. After the decision, work is further given to individuals to carried
out desired modifications.

II. Management of Changes: - It is an important activity for the implementations of

any change. Whenever a request is received for any addition/modification a change
33
 request is created through a specified request form. The request is analyzed due to its
impact or overall project cost, resources allocated and delivery schedule of the project.
After the implementation of any change, a formal notice is issued to all stakeholders.

III. Documentation: - It is required to keep track of every activity of the project. Success
of any software project lies in the documentation. It is very pertinent to note that without
documentation, project future is in dark and with every passing day, it leads towards
disaster.

IV. Requirement Traceability: - It is a technique to provide relationships between

requirements, design and implementation in order to manage the effect of change and its
impact on the success of the project. Every requirement should be traceable any and
every piece of design work may be traced to one or more requirements in the project.

V. Communication of Change: -The most problematic changes to the requirement

specification have been the ones that are not communicated to every stakeholder.
Communication failures typically occur when we may drop a feature or change a
performance requirement without communication to others.

VI. Establishment of Baseline: -After the approval of a change, it is communicated to

all. If every stakeholder agrees to the change, it is implemented and tested. Baseline is the
tested version of a set of requirements representing a conceptual milestone, serves as the
basis for further development. The steps for baseline establishment are:

• Approval of change from competent authority.

• Communicate the approval to all stakeholders.

• History of change is maintained.

34
 Chapter 4
Tools of requirement engineering

Accept 360° from Accept Software Corporation

It is a requirements management tool that also supports product planning. Tools help
users to define and track feature dependencies with tree diagrams, and to relate these to
the market, project plans, implementation considerations and competitor analyses.

Accompa from Accompa

It is a requirements management service provided on the Web for a small monthly fee per
user. It can be customised with any number of fields and reports using sorts and filters. It
has Web 2 style collaboration mechanisms for discussing and agreeing requirements. A
Wizard guides the creation of specifications, which can be exported to Word, HTML,
Excel, PDF.
Raj Patel of Accompa, Inc. writes: "Accompa is an affordable, web-based requirement
tool that enables product managers and project managers to capture, track and manage
requirements. It can be customized right from the web-interface to fit an organization's
needs. It features extensive collaboration features such as integrated discussion boards
and social tags. A 30-day free trial is available."

35
Active Focus from Falafel Software (formerly Xapware)
It is said to support the software application life-cycle.

Agility from Agile Edge

It is a tracking database for user requirements, issues, tasks and bug tracking, permitting
tracing between these items. There is a simple user interface displaying a table of items
with status, symbols and text.

Agilo for Scrum from Agile 42

It is a tool for Scrum implementation, agile development, requirements and user stories.
Marion Eickmann of Agile42 writes: "Even if Agilo is not a pure requirements tool, we strongly
connect the Scrum ideas with requirements engineering."

Aligned Elements from Aligned AG

It is a tool for handling requirements traceability and risk in the medical device industry.
It includes a Requirements Management module. Its purpose is to handle all the evidence
needed in the strict regulatory environment of medical devices. This seems to represent a
trend (cf Comply Pro) towards specialised products performing essentially familiar RM
tasks but using the language of a particular domain.
Karl Johan Larsson of Aligned writes: "Aligned Elements is a requirement management
solution targeted towards the Medical Device industry and is essentially built to manage
Design History Files. Aligned Elements incorporate all relevant parts of the DHF
Management process such as specifications, test cases, FMEA risk analysis, structured
reviews, trace analysis, validation checks and is controlled by FDA QSR 21 CFR Part 11
user management etc."

Arcway Cockpit from Arcway AG

It is a visual RE tool in which written requirements provide the bridge between different
"visual landscapes" such as the business landscape and the IT landscape. The
"landscapes" are defined visually with block diagrams or "maps" showing interfaces
between people, processes, and software. The diagramming notation and visual concept
seems to be unique to Arcway, while the idea of tracing between business processes and
IT systems is classical but very freshly expressed. The examples seem to be strongly
oriented to transactions and databases: whether the concept would work for other kinds of
systems is unclear, though the principle of connecting events in the world to events and
structures in the machine is quite general. This looks like the most exciting new product
of 2007.
Peter Aschenbrenner of Arcway AG writes:
"ARCWAY Cockpit is a tool for managing requirements. It supports ARCWAY’s concept

36
of visual requirements engineering (VRE). In VRE requirements are linked to visual
high-level models of the system under design. Requirements specified in ARCWAY
Cockpit can be imported from and exported to MS Excel. A fully customizable MS Word,
HTML and Docbook report interfaces allows for ad-hoc reports of specific requirements
or complete specification documents."

ARM (Automated Requirement Measurement) from NASA

It is a simple tool that carries out a set of checks on a list of (shall-statement)
requirements in plain text. As such it can be applied to almost any set of contractual style
requirements just by exporting them to a plain text file and then running ARM. It helps to
find a range of possible problems. Once you get the idea, it is easy to re-implement a set
of ARM-like rules with your own extras in a scripting language.

Banana Scrum from CodeSprinters

It is a web-based project support tool for agile software development, using the Scrum
method, and suitable for use with programming languages such as Python and Ruby on
Rails. Requirements are captured on the equivalent of index cards and immediately coded
in short iterations known as Sprints.

Blueprint from Blueprint Inc.

This tool (formerly Profesy) won the 2005 Gartner Cool Vendor prize for being
“innovative, impactful, and intriguing”. It was sold as a 'Visual Requirements Definition
and Validation product' and is said to integrate intelligently with a range of 3rd-party
tools. It assists with the creation of requirements, flowcharts, test scenarios and
documentation.
Tony Higgins of Sofea writes:
Profesy provides a unified approach to Requirements Definition and Test Development.
1) For Requirements Definition, it provides business analysts with a powerful workbench
to model, simulate, and validate business processes, business requirements and system
requirements together to create a collaborative and highly visual elicitation, definition
and approval process. 2) For Test Development, Sofea provides test planners with a
powerful test development workbench to analyze requirements and automatically
generate test scenarios. Test planners can incorporate scope and policy driven test
strategies into the requirements model (to drive multi-level, risk, impact, regression
testing). 3) After establishing a baseline, Sofea’s powerful integration capability is used
to extract formal artifacts such as requirements and tests into leading Requirements
Management, Design and Test Execution platforms. The resulting impact is that test

37
planning is completed early in the development project and all tests are 100% traceable
to high-quality validated requirements.

Caliber-RM from Borland

It is a well-known requirements management tool. It is intended for large and complex
systems, and provides a database of requirements with traceability. The company views
requirements as part of the software quality management process, which it considers also
includes testing and defect tracking. Caliber is Internet-based, and it handles document
references, user responsibility, traceability, status and priority.
Chip Carey of Starbase (former owners of Caliber) wrote:
"The exciting thing about RM and Caliber RM in particular is that it brings all
departments together within the software development lifecycle and puts them all on the
same page - it provides a mechanism for communication and collaboration and
effectively provides a synergy where before they were perhaps separate efforts and
maybe counter-productive."

CASE SPEC (formerly AnalystPro) from Goda Software

It supports requirements editing and traceability, change control, diagrams including use
cases, and other features of full RM tools at a low price per seat.
CASE Spec is described as a "Specification, Requirements & Lifecycle Solution".
Kris of Goda Software, Inc writes:
Analyst Pro is an affordable, scalable and collaborative tool for requirements tracking,
traceability analysis and document management. It is easily deployable and customizable
to your project needs."

38
 Conclusion
Fritz Bauer defined software engineering as “The establishment and use of sound engineering
principles in order to obtain economically developed software that is reliable and works
efficiently on real machines.”
Stephen Schach defined the same as “A discipline whose aim is the production of
quality software, software that is delivered on time, within budget, and that satisfies its
requirements.”
Requirements analysis in systems engineering and software engineering, encompasses those
tasks that go into determining the needs or conditions to meet for a new or altered product, taking
account of the possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users. Requirements analysis is critical to the success of a development project.
Requirements must be actionable, measurable, testable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design.
Thus we can conclude that, “Requirements engineering is the branch of
software engineering concerned with the real world goals for, functions of,
and constraints on software systems. It is also concerned with the relationship
of these factors to precise specifications of software behavior, and to their
evolution over time and across software families.”

39