Software Requirements

Introduction
I The software requirements is documentation that completely
describes the behaviour that is required of the software before
the software is designed, built and tested.
I Programmers could build software that they intend to use
themselves - the programmer does not need to take time to
understand the behaviour of the software.
I However, most software is built to meet the needs of someone
other than the programmer.
3 / 12
Software Requirements Engineering
I Software Requirements Engineering is the art and science
of developing an accurate and complete definition of the behaviour
of software that can serve as the basis for software
development.
I Like project management, programming, and testing, software
requirements engineering encompasses a set of skills
that require training and practice.
I Software requirements engineering tasks are usually performed
by skilled requirements analysts (who sometimes
have the title Business Systems Analyst)
4 / 12
Requirements Elicitation
I Requirements elicitation is the process through which a requirements
analyst gathers, understands, reviews, and show
the needs of the software project’s stakeholders and users.
I The objective of this activity is to create a complete list of
what the users believe are important requirements.
I Elicitation activities can include:
I Interviews with the users, stakeholders, and anyone
else whose perspective needs to be taken into account
during the design, development, and testing of the software
I Questionnaires
I Distribution of discussion summaries to verify the data
gathered in interviews
5 / 12
Conduct Interviews
I Interviews are the most straightforward and effective practice
for doing requirements elicitation.
I The goal of the interview is to identify specific needs that
the person being interviewed has for the software.
I The first step in conducting interviews is to identify who the
interviewees should be.
I If the software is being built for a specific industry or
area of expertise, the requirements analyst may need
to seek out subject matter experts in that area.
I When the software is intended to be marketed or sold,
sales and marketing personnel are considered subject
matter experts.
I If the goal of the project is to enhance or maintain an
existing software, then the interviewees should include
actual external users.
6 / 12
Interview Questions
I Why is the software being built? What benefits will the interviewee
directly see? What benefits will other people in the
organization see?
I What problems need to be addressed with new software?
Why do those problems exist? How would you solve them?
I Who will use the software once it is built?
I In what environment will the software be used? Will it be
run within the organisation or by its customers?
I Are there any known constraints on the performance, design,
or quality of the software?
I What inputs will be used by the software? What outputs will
it create?
7 / 12
Observe Users at Work
I Observing a user’s workflow in the context of his or her environment
allows a requirements analyst to see problems that
the user encounters with the current system and to identify
ways to enhance the behaviour of the software.
I Watching users at work provides a more accurate understanding
of their activities than simply asking them to communicate
the steps involved in performing their tasks.
I Often there are many details that someone familiar with a
task might not think to mention, but that are very important
for the requirements analyst to fully understand the task.
I There are already people in the organisation who are doing
work that is relevant to the behaviour of the software.
8 / 12
Questionnaires
Within the computing field, questionnaires are commonly used
to elicit information from users during the requirements engineering
phase of a software project.
The advantages
I Questionnaires are relatively cheap and fast when compared
to interviews
I They allow for relatively large numbers of the sampling
frame to be surveyed
I Questionnaires facilitate easy statistical analysis of the results,
when they are well designed
9 / 12
Use cases
I A use case is a description of a specific interaction that a
user may have with the system.
I Use cases are simple tools for describing the functionality
of the software.
I Use cases do not describe any internal workings of the
software, nor do they explain how that software will be
implemented.
I They simply show how the steps that the user follows
to use the software to do his work.
I All of the ways that the users interact with the software
can be described in this manner.
10 / 12
The ATM use cases example
11 / 12
The State Diagram of the ATM use case
12 / 12