CHAPTER 3

SOFTWARE REQUIREMENT
ELICITATION AND ANALYSIS
WHAT IS SOFTWARE REQUIREMENT??

• Requirements describe the ‘what’ of a system and not the ‘how’. ‘What’ is related to
expectations from a system.
• According to IEEE, a requirement is defined as:
1. A condition or capability needed by a user to solve a problem or achieve an
objective.
2. 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.
3. A documented representation of a condition or capability as in 1 and 2.
 STAKEHOLDERS
• Stakeholders are those peoples who are affected directly or indirectly from
the software being developed. Stakeholders are broadly classified in 4
categories:
1. Internal people of customer organization
2. External people of customer organization
3. Internal people of developer organization
4. External people of developer organization
• Functional Requirements:
They describe ‘what’ the software will do. This ‘what’ part gives us the functional requirements which
are nothing but the expectations from the system. Functional requirements are also called product
features.
• Non Functional Requirements:
They are nothing but the attributes of software quality. They signify that how well the software does
what it has to do. Non-functional requirements are important for the sustainability of the system and
some of them are reliability, usability, maintainability, availability, portability, flexibility and testability.
• Domain Requirements:
Domain requirements are expectations related to a particular type of software, purpose or industry
vertical. Domain requirements can be functional or nonfunctional. The common factor for domain
requirements is that they meet established standards or widely accepted feature sets for that category
of software project. Domain requirements typically arise in military, medical and financial industry
sectors, among others. One example of a domain requirement is for software in medical equipment:
The software must be developed in accordance with IEC 60601 regarding the basic safety and
performance for medical electrical equipment.
• Known and Unknown Requirements:
Known requirements are the expectations of the stakeholders and may make
stakeholders happy if implemented correctly. Unknown requirements are
forgotten by the stakeholders because they may not require now or due to
limitation of domain expertise and facilities of available technology. If such
unknown requirements are identified, they may add value to the system and may
increase the chances of acceptability and sustainability of the system.
 REQUIREMENT ELICITATION
• According to Wiegers(1999), “Requirements elicitation is perhaps the 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”.
• There are many techniques for requirements elicitation. We may use one or
more techniques to capture the requirements.
 INTERVIEWS
• The most popular, simple and conventional requirements elicitation technique is to
conduct interviews with the customer. After receiving the request for software
development, we would like to understand the project.
• The interview of the customer may be informal (non-structured) or formal
(structured). The first such meeting/interview may help to understand broad
expectations. In the informal interview, there is no fixed agenda and open
discussions for free flow of view are encouraged.
• . In the structured interview, a proper agenda is prepared along with a questionnaire
 BRAINSTORMING SESSIONS
• A group of various stakeholders is constituted to discuss the requirements. The size of the
group may be from 5 to 15 persons.
• The sessions should be conducted in a conference room with at least two whiteboards and
other presentation devices like projector. A facilitator should be there.
• Every stakeholder is allowed to give his/her views using the projector and whiteboard. All
views are documented. Every idea is written in such a way that everyone can see it.
• After the session, a detailed report is prepared and the same may be reviewed by the
facilitator. All ideas are written in a simple and easy language so that they convey the same
meaning to every stakeholder.
 FACILITATED APPLICATION
SPECIFICATION TECHNIQUE(FAST)
• This is a team-oriented approach and works on the pattern of brainstorming
sessions. A joint team of customers and developers is constituted to frame
the requirements. All meetings are conducted under the chairpersonship of a
facilitator.
• Facilitated application specification technique (FAST) is more formal than
brainstorming sessions. All members of the team are required to follow the
set of procedures and guidelines.
 GUIDELINES
1. FAST session must be conducted at neutral site. All members of the joint team
(developers and customers) travel to that site. This may help to get their maximum
involvement and focus on the requirements capturing.
2. Rules for participation are framed and circulated to all members in advance.
3. All members are made comfortable to encourage free flow of ideas.
4. The facilitator gives the overview of the project.
5. A display mechanism like projector, wall stickers, flip charts, whiteboards, etc. should be
available in the committee room where the meeting is conducted.
6. All members should be directed to give only their views. Unnecessary prolonged debates
and criticisms should be avoided.
 ACTIVITIES OF FAST SESSION
• Each member presents his/her lists of objects, constraints, services and performance for
discussion. A list may be displayed using any display mechanism (say projector) or may be
written on the whiteboard in such a way that it is visible to every team member of the team.
• A small group is constituted to prepare a consolidated list after removing redundant entries.
• The convener of the small group presents the consolidated list. Discussions take place
under the directions of the facilitator. The list is further modified, if required, in order to
prepare a consensus list.
• A few small groups are constituted to draft mini-specifications for one or more entries of
the consensus list.
 ACTIVITIES CONTD…
• Each subteam presents mini-specifications to all FAST attendees. After
thorough discussions, modifications are carried out in mini-specifications.
• Some issues may not be resolved during the meeting. A list of such issues is
prepared for consideration at any later stage.
• A validation criterion is also decided for every requirement.
• A subteam for drafting the specification is constituted. The final draft is
prepared considering all inputs of FAST meeting.
 PROTOTYPE
• A prototype is a simplified version of the system. When it is shown to the customers, they
get an idea about the final system. At this point, their feedback and views are very important
and may help us to read their minds.
• Prototyping is the rapid development of a system for the purpose of understanding
requirements. Customers and users can use the prototype to see how the system will look
and behave finally.
• According to Schach (1999), “The developers should develop the prototype as early as
possible to speed up the software development process. After all, sole use of this is to
determine the customer’s real needs. Once this has been determined, the prototype is
discarded. For this reason, the internal structure of the prototype is not very important”.
INITIAL REQUIREMENT DOCUMENT

• After the requirements are captured, the initial requirements document (IRD)
may be prepared.
• The IRD is used to document and list the initial set of requirements gathered
through various stakeholders.
 TEMPLATE OF IRD

Title of the project

Stakeholders involved in capturing
requirements
Techniques used for requirement capturing
Name of the persons along with designations
Date
Version
Consolidated list of initial requirements
 USE CASE APPROACH
• The use case approach is primarily designed for object-oriented systems. However,
the same may also be used for traditional systems to represent and analyse
requirements and for modelling them in a systematic way.
• The use cases address only the functional requirements which explain the
expectations of users sitting outside the system.
• Use cases are structured outlines or templates for the description of requirements,
written in a natural language like English. A use case scenario is an instance of a use
case. It represents a path through a use case. Use case diagrams are graphical
representations that may be decomposed into further level of abstraction.
 USE CASE AND ACTORS
• Use cases incorporate anything that is within the system, but and actors include
anything that is external to the system.
• A use case is initiated by an actor with a specific purpose in mind and completes
successfully when that purpose is achieved. The use case describes the sequence of
interactions between actors and the system to fulfil the desired purpose.
• An actor is someone or something that interacts with the system and lies outside the
system. The actor may be users of the system, customers, persons giving
information to the system or any external system providing data.
 IDENTIFICATION OF ACTORS
• An actor interacts with the system with a particular purpose. The actor may be a
person or external system.
• There are two types of actors—primary actors and secondary actors. Primary actors
are the persons who will use the system. Secondary actors are the persons who will
maintain or monitor the system.
 IDENTIFICATION OF USE CASES
• Use cases describe the functionality of the system. To achieve that functionality, actors
interact with the system with a defined purpose.
• Every specified functionality should have a use case.
• A unique name is assigned to a use case. The name should be meaningful and should be able
to indicate the purpose of a use case.
• One or more actors may interact with a use case.
• The use case should describe the sequence of actions.
• The use case is initiated by an actor with a specified purpose. Role of actors must be defined
clearly. The use case should represent a complete and meaningful flow of events.
 Defining Relationship Between Use Cases

• Extend relationship: Extend relationship is used to model the occurrence

of some optional, alternative or special part of the use case. This relationship
is used to extend the functionality of the original use cases.
• Include relationship: The redundant and repeated functionalities amongst
use cases can be modelled into include relationship. Thus, the redundancies
can be grouped into a single use case. In order to use include relationship,
there must be common text in two or more use cases.
Extend Relationship Include Relationship
 USE CASE DIAGRAM
• Use case diagram represents the top view of the system. The use cases reside
within the system and the actors act from outside the system.
• The use case diagram is also used to present functionality of the system, but
for proper explanation, it should read along with use cases.
• The use case diagram may also be decomposed into further level of
abstraction. It also shows the relationship of use cases and actors. It also
explains what happens when an actor interacts with the system.
 USE CASE DESCRIPTION
• Basic flow: It is the main flow and describes the sequence of events that
takes place most of the time between actor and the system to achieve the
purpose of the use case.
• Alternative flows: If the basic flow is not successful due to any condition,
the system takes an alternative flow. An alternative flow may occur due to
failure of an expected service because of occurrence of exceptions/errors.
There may be more than one alternative flow of a use case, which may not
occur most of the time. Any alternative flow takes place under certain
conditions in order to fulfil the purpose of a use case.
 USE CASE DESCRIPTION TEMPLATE
Introduction:
Actors:
Pre conditions
Post conditions
Flow of Events:
Basic Flow:
Alternative Flow:
Special Requirements
Associated Use cases
 LOGIN:
Introduction:
This use case describes all the steps followed in order to login into tenant management system.
Actors: Administrator , Tenant , Support staff
Pre-conditions:
Administrator/Tenant/Support staff must have valid username and password.

Post conditions:
If username and password is valid, the actor is successfully logged in to the system; else an error message will be displayed.

Flow of Events:
Basic flow:
The system will request the actor to enter their login details for the system The actor fills in the following details:
 Username
 Password
If login details are valid after clicking the login button, the actor is successfully logged into the system
Alternate Flows:
Alternative Flow 1: Invalid Entry
If username/password entered by actor is invalid or if any field username /password are empty then the system will display an error
message and the actor returns to the basic flow.
Alternative Flow 2: User Exits
User can exit at any time and use case ends.
Special requirements: None
Associated use cases: None
 USE CASE SCENARIO
• A use case scenario is an instance of a use case. This is nothing but a path
through a use case. A use case may have many paths. A basic flow is a path
which is expected to be traversed most of the time and becomes a scenario
of the use case. Every alternative path also generates a scenario.
• The basic flow is represented by a straight arrow and the alternative flows by
the curves. Some alternative flows return to the basic flow, while others end
the use case. Preconditions and postconditions are checked at start and end
points of a use case, respectively
 CHARACTERISTICS OF A GOOD
REQUIREMENT
• Correct
• Unambiguous
• Complete
• Consistent
• Verifiable
• Modifiable
• Clear
 CHARACTERISTICS
• Feasible
• Necessary
• Understandable
 SOFTWARE REQUIREMENT
SPECIFICATION(SRS)
• SRS is a detailed document prepared on the basis of IRD.
• This document is used as a legal document which acts as a contract between
customers and developers.
• On the basis of this document, the developers know what to build, and the
customers know what to expect, and this document may also be used to
validate that the built system satisfies the requirements.
• We use IEEE recommended practice for software requirements
specifications—IEEE standard 830-1998 for preparing the SRS document.
 NATURE OF SRS
• Functionality
• External interfaces
• Performance
• Quality attributes
• Design constraints imposed on implementation
• The SRS writer(s) should not include design and implementation details. It should
be written in a simple, clear and unambiguous language which may be
understandable to all developers and customers.
 Requirement Change Management
• Requirements change management is a new area which has been rapidly
adopted by the software industry. As we all know, changes in requirements
are inevitable. Many times, we make changes due to factors beyond our
control.
• Requirements change management is a systematic process of understanding
and controlling changes in requirements. Any change in the requirements is
not an independent activity and may have impact on other requirements,
which make the area much more difficult and challenging.
 STEPS FOR CHANGE MANAGEMENT
• Is Change Necessary?? : After receiving a change request, a study is carried out to
know whether a change is necessary or not. Hence, all changes must be considered
by a committee and action is taken on the merits of every change. The committee
may not accept every change request.
• Baseline Establishment: After the approval of a change by the committee, it is
communicated to all the stakeholders. They may give their views about the change
and the same may be considered by the committee. Important views are noted and
an appropriate action is recommended. If the change is finally approved, it is
implemented and tested. Baseline is the tested version of a set of requirements
representing a conceptual milestone, and serves as the basis for further
development.
 STEPS CONTD….
A particular version of the software becomes the baseline when a responsible group
decides to designate it as such (Aggarwal and Singh, 2008). Baselining is nothing but
labelling a set of requirements at specific versions and freezing them before
proceeding to the next phase of development. History of changes must be maintained.
All documents should also be updated after incorporation of any change.
• Requirement Traceability: Requirements traceability is a well-proven technique
that extends from initial requirements to use cases and from there to design,
implementation and testing. The ability to keep track of these relationships is a key
to produce high-quality software development. Requirements traceability is essential
to ensure the correctness of each step of software development process.
 STEPS CONTD…
The purpose of traceability is to:
Understand the origin of the requirements.
Manage the change.
Assess the impact of change in any requirement on the software system.
Verify that all the requirements have been implemented.
Verify the functionality of the software
 STEPS CONTD…
• Change Control: A change in requirements is a regular activity. There are two important
issues; one is proper documentation of change and impact of the change. The change
request form documents the description of change. Its impact on other parts is also
analysed and documented. All these information is submitted to the change control
authority (CCA) to take a decision about acceptance of change request.
If decision of the CCA is in favour of accepting a change, then the CCA issues an approval
of change. After this, the change is implemented. The revised software is handed over to the
software quality assurance (SQA) team for revalidation and also to ensure that the change has
not adversely affected other parts of the software. The modified software is handed over to the
software configuration team and is incorporated in a new version of the system.
Change Request Form
1. Title of the project:
2. Name of change request:
3. Date of change request:
4. Requested change description:
5. Affected parts of source code:
6. Estimated cost of change:
7. Priority of change:
8. Assessment of change:
9. Date of submission of change request to change control authority(CCA):
10. Decision od CCA with date:
11. Name of change implemented:
12. Date of implementation:
13. Date of submission to QA:
14. Decision of QA:
15. Submission to configuration team with date:
16. Action of configuration management team: