Mizan-Tepi University

Chapter-4
Software Requirement Analysis

Compiled By: Fikadu M.

Mar, 2024
 What Is A Requirement?
 At its most basic, a requirement is a property that must be

exhibited by a software

 in order to solve some problem in the real world.

 It may range from a high-level abstract statement of a service

or of a system constraint to a detailed mathematical

functional specification.

2
 What Is A Requirement?cont…
 Requirements define the function of the system from the

client's viewpoint.

 The requirements establish the system's functionality,

constraints, and goals by consultation with the client,

customers, and users.

 The requirements may be developed in a self-contained

study, or may emerge incrementally.

 The requirements form the basis for acceptance testing.

3
 What Is A Requirement?cont…

 The development team and the client need to work

together closely during the requirements phase of a

software project.

 The requirements must be developed in a manner that is

understandable by both the client and the development

staff.

4
 Why Are Requirements Important?
Causes of failed software projects (Standish study)
 Incomplete requirements 13.1%

 Lack of user involvement 12.4%

 Lack of resources 10.6%
 Unrealistic expectations 9.9%
 Lack of executive support 9.3%

 Changing requirements & specifications 8.8%

 Lack of planning 8.1%

 System no longer needed 7.5%

 Failures to understand the requirements led the developers

to build the wrong system.
5
Requirements In Iterative Refinement

6
 Requirement Goals
 Understand the requirements in appropriate detail.

 Define the requirements in a manner that is clear to the

client. This may be a written specification, prototype

system, or other form of communication.

 Define the requirements in a manner that is clear to the

people who will design, implement, and maintain the

system.

 Ensure that the client and developers understand the

requirements and their implications.

7
 How Can We Classify Requirements?

 Functional / Non-functional requirements

 A functional requirement describes a function/service

that the software is to execute/provide.

 Sometimes known as capability or feature.

 A non-functional requirement is a constraint on the

provided functions/services.

 Sometimes known as constraints or quality requirements

 e.g. reliability, response time, maintainability, scalability,

portability, availability , security and storage requirements.8

 How Can We Classify Requirements? cont…
 User requirements
 It define result and qualities that the user needs, wants from
the system
 The user requirement is owned by user.
 The main task is to help users express their needs in
writing.
 Written for customers.

 System requirements

 It define what the system must do to achieve this

 A statement that identify the functionality that is needed
by a system in order to satisfy the customers
requirements
9
 Software Requirement Process
.

10
 Requirements Elicitation

 Requirements elicitation is the first stage in building an

understanding of the problem the software is required to

solve.

 It is fundamentally a human activity and is where the

stakeholders are identified and relationships established

between the development team and the customer.

 It is variously termed requirements capture, requirements

discovery, and requirements acquisition.

11
 cont…
 Interviews - Interviewing stakeholders is a
“traditional” means of eliciting requirements.

 Types of interviews
 Closed interviews based on pre-determined list of
questions
 Open interviews where various issues are explored with
stakeholders.

 Effective interviewing

 Be open-minded, avoid pre-conceived ideas and be

willing to listen to stakeholders.

12
 cont…

 Interviews in practice

 Normally a mix of closed and open-ended interviewing.

 Interviews are good for getting an overall understanding of

what stakeholders do and how they might interact with the

system.

13
 Requirement Analysis
Scenarios:

 Scenarios are real-life descriptions of how a system can be

used.

 Scenarios are a tool for requirements analysis.

 They are useful to validate use cases and in checking the

design of a system.

 They can be used as test cases for acceptance testing.

14
 Requirement Analysis cont…

 Lets see one example how to develop a scenario with a

client

 The requirements are being developed for a system that will

enable MTU students to take exams online from their own

rooms using a web browser.

 Create a scenario for how a typical student interacts with

the system.

15
 Requirement Analysis cont…

 Purpose: Scenario that describes the use of an online Exam

system by a representative student. e.g Student A

 Individual: [Who is a typical student?] Student A, @MTU, in

Computer Engineering.

[Where can the student be located? Do other universities

differ?]

 Equipment: Any computer with a supported browser.

[Is there a list of supported browsers? Are there any network

restrictions?]
16
 Analysis Techniques cont…
 Scenarios:
1. Student A authenticates. [How does a MTU student
authenticate?]
2. Student A starts browser and types URL of Exam system.
[How does the student know the URL?]
3. Exam system displays list of options. [Is the list tailored to
the individual user?]
4Student A selects SE 1234 Exam 1.
5. A list of questions is displayed, each marked to indicate
whether completed or not. [Can the questions be answered in
any order?]
6. Student A selects a question and chooses whether to
submit a new answer or edit a previous answer. [Is it always
possible to edit a previous answer? Are there other options?]
17
 Requirement Analysis cont…
 Scenario:

7. The first question requires a written answer. Student A is

submitting a new answer. The student has a choice whether to
type the solution into the browser or to attach a separate file.
Student A decides to attach a file.
[What types of question are there: text, multiple choice, etc.?]
[What types of file are accepted?]
[Link] the second question, the student chooses to edit a
previous answer. Student A chooses to delete a solution
previously typed into the browser, and to replace it with an
attached file.
[Can the student edit a previous answer, or must it always be
replaced with a new answer?]
18
 Requirement Analysis cont…
 Scenario:

9. As an alternative to completing the entire exam in a single

session, Student A decides to saves the completed questions
work to continue later.
[Is this always permitted?]
10. Student A logs off.
11. Later Student A log in, finishes the exam, submits the
answers, and logs out.
[Is this process any different from the initial work on this exam?]

19
 Requirement Analysis cont…
 Scenario:

9. As an alternative to completing the entire exam in a single

session, Student A decides to saves the completed questions
work to continue later. [Is this always permitted?]
10. Student A logs off.
11. Later Student A log in, finishes the exam, submits the
answers, and logs out.
[Is this process any different from the initial work on this exam?]
[Link] Student A has now completed the exam. The student
selects an option that submits the exam to the grading
system.
[What if the student has not attempted every question? Is the
grader notified?] 20
 Requirement Analysis cont…
 Scenario:

13. Student A now wishes to change a solution. The system

does not permit changes once the solution has been
submitted.
[Can the student still see the solu7ons?]
14. Later Student A logins in to check the grades.
[When are grades made available? How does the student
know?]
15. Student A requests a regrade.
[What are the policies? What are the procedures?]

21
 Requirement Analysis cont…
 Generally:

 Developing a scenario with a client clarifies many functional

requirements that must be agreed before a system can be

built, e.g., policies, procedures, etc.

 The scenario will often clarify the requirements for the user

interface.

22
 Requirement Modeling
Use-cases:
 Use cases are a tool for modeling requirements.

 A set of use cases can provide a framework for the

requirements specification.

 A use case diagram shows the relationships between actors

and their interactions with a system.

 An actor is a user(human, external system.) of a system in a
particular role.
 A use case is a a task that an actor needs to perform with the
help of the system.

23
 Requirement Modeling cont…

Simple use case diagram

use case
Actor
24
 Requirement Modeling cont…
Outline of Take Exam Use Case
 Name of Use Case: Take Exam
 Actor(s): ExamTaker
 Flow of events:
1. ExamTaker connects to the Exam server.
2. Exam server checks whether ExamTaker is already
authenticated and runs authentication process if
necessary.
3. ExamTaker selects a exam from a list of options.
4. ExamTaker repeatedly selects a question and either types
in a solution, attaches a file with a solution, edits a solution
or attaches a replacement file.

25
 Requirement Modeling cont…
5. ExamTaker either submits completed exam or saves
current state.

6. When a completed exam is submitted, Exam server checks

that all questions have been attempted and either sends
acknowledgement to ExamTaker, or saves current state and
notifies ExamTaker of incomplete submission.

7. ExamTaker logs out.

Entry conditions:
1. ExamTaker must have authentication credentials.
2. Computing requirements: supported browser. 26
 Software Requirement Specification (SRS)?
 SRS is a document that describes requirements for a software
product, program or set of programs.

 SRS represents the results of the requirements analysis and

describes the requirements of the software under
development.

 Requirement specification, also known as documentation, is a

process of jotting down all the system and user requirements
in the form of a document.

 These requirements must be clear, complete, comprehensive,

and consistent.
27
 What Makes A Good SRS ?

[Link] should be correct

 An SRS is correct if, and only if, every requirement stated therein is
one that the software should/shall meet.

 There is no tool or procedure that ensures correctness.

 The SRS should be compared with any applicable superior

specification,

 such as a system requirements specification, with other project

documentation, and with other applicable standards, to ensure that
it agrees.

 Alternatively the customer or user can determine if the SRS

correctly reflects the actual needs. 28
 What Makes A Good SRS Cont…

[Link] should be unambiguous

 An SRS is unambiguous if, and only if, every requirement

stated therein has only one interpretation.

 As a minimum, this requires that each concept/characteristic

of the product be described using a single unique term.

[Link] should be complete

 An SRS is complete if, and only if it includes:

 All significant requirements.

29
 What Makes A Good SRS Cont…

 Definition of the responses of the software to all realizable

classes of input data in all realizable classes of situations..

 Definition of the responses of the software to all realizable

classes of input data in all realizable classes of situations.

Note that it is important to specify the responses to both
valid and invalid input values.

 Full labels and references to all figures, tables, and

diagrams in the SRS and definition of all terms and units of

measure.
30
 4. It Should Be Consistent
 SRS is internally consistent if, and only if, no subset of

individual requirements described in it conflict.

 Consistency refers to internal consistency. If an SRS does

not agree with some higher-level document, such as a

system requirements specification, then it is not correct.
 The specified characteristics of real-world concepts may
conflict.
 For example:
a) The format of an output report may be described in one
requirement as tabular but in another as textual.
b) One requirement may state that all lights shall be green
while another may state that all lights shall be blue.
31
 Cont..
 There may be logical or temporal conflicts between two
specified actions.
 For example οne requirement may state that A must always
follow B, while another may require that A and B occur
simultaneously.
 Two or more requirements may describe the same real-
world object but use different terms for that object.

 For example, a program’s request for a user input may be

called a prompt in one requirement
 and a cue in another.

32
 5. It Should Be Ranked For Importance
 An SRS is ranked for importance if and only if each
requirement in it has an identifier to indicate the importance
of that particular requirement.
 Essential - Implies that the software will not be acceptable
unless these requirements are provided in an agreed
manner.
 Conditional - Implies that these are requirements that would
enhance the software product, but would not make it
unacceptable if they are absent.
 Optional - Implies a class of functions that may or may not
be worthwhile. This gives the supplier the opportunity to
propose something that exceeds the SRS.

33
 6. It Should Be Ranked For stability

 An SRS is ranked for stability if and only if each requirement

in it has an identifier to indicate the stability of that

particular requirement.

 Stability can be expressed in terms of the number of

expected changes to any requirement based on experience

or knowledge of forthcoming events that affect the
organization, functions, and people supported by the
software system.

34
 7. It Should Be Verifiable

 An SRS is verifiable if, and only if, every requirement stated

therein is verifiable.

 A requirement is verifiable if, and only if, there exists some

finite cost-effective process with which a person or machine

can check that the software product meets the requirement.

 In general any ambiguous requirement is not verifiable.

35
 7. It Should Be Verifiable
 Examples of non-verifiable requirements are statements
such as:
 “works well”, “good human interface” and “shall usually
happen”
 An example of a verifiable statement is:
 Output of the program shall be produced within 20 s of event
X 60% of the time; and shall be produced within 30 s of event Y
100% of the time.
 This statement can be verified because it uses concrete
terms and measurable quantities.

36
 8. It Should Be Modifiable
 An SRS is modifiable if, and only if, its structure and style are
such that any changes to the requirements can be made
easily.

 SRS must have a coherent and easy-to-use organization with

a table of contents, an index, and explicit cross-referencing.

 Not be redundant (i.e., the same requirement should not

appear in more than one place in the SRS).

 Express each requirement separately, rather than intermixed

with other requirements.

37
 9. It Should Be Traceable

 An SRS is traceable if the origin of each of its requirements is

clear and facilitates the referencing of each requirement in

future development or documentation.

 Backward traceability - each requirement must explicitly

reference its source in earlier documents.

 Forward traceability - each requirement in the SRS must

have a unique name or reference number.

38
39