Lecture III

Requirements/Systems analyst
Person performing the tasks of determining
the requirements for a proposed software
system
(problem analysis) breaking down what the
customer wants into discrete requirements

Requirements

Specification and Design

Specification makes decisions on which
requirements will be fulfilled by our software
system

Goal of requirements phase

understand the customers problems and needs

As opposed to those that are addressed by special

purpose hardware devices, by other software
systems or by human operator or users

What is requirements?
An expression of desired behaviour
Deals with objects/entities, states they can be
in, and functions that are performed to change
state or object characteristics
Designates what behaviour the customer wants
without saying how the behaviour will be
realised

In design, a plan is devised as to how the

specified behaviour will be implemented
3

Requirements process

Requirements Process - Analysis

Requirements Process Elicitation

Understanding and modelling the desired

behaviour

Collecting the user requirements by:

Modelling or prototyping the requirements

helps us to better understand the required
behaviour
Also raises additional questions about what the
customer wants to happen in certain situations

Asking questions
Examining current behaviour
Demonstrating similar systems

May expose problems or omissions in our

models that cause us to revisit the customer
and revise our models
9

Requirements Process - Specification

10

Requirements Process - Validation

Checking that our specification matches the
users requirements

Documenting the behaviour of the proposed

software system

Matches developers specifications with users

expectations of the final product

Requirements are well understood

Then it is decided which parts of the required
behaviour will be implemented in this software
system

May expose problems or omissions in our

specifications that cause us to revisit the
customer and revise our specifications
11

12

Requirements Process Software

Requirements Specifications (SRS)

Requirements Elicitation
Critical part of the process

Eventual outcome of the requirements process

Must use a variety of the techniques to
determine what the users and the customers
really want

Is used to communicate to the other software

developers (designers, testers, maintainers)
how the final product ought to behave

Discussion with everyone who has a stake in the

system and coalescing these different views into
a coherent set of requirements
13

Stakeholders in Requirements
Elicitation Process
1.
2.
3.
4.
5.
6.
7.

Clients
Customer
Users
Domain Experts
Market Researchers
Lawyers or auditors
Software engineers or other technology experts

15

Stakeholders in Requirements
Elicitation Process

14

Stakeholders in Requirements
Elicitation Process
Clients
Pay for software to be developed
Ultimate stakeholders as they have final say on what
product does

Customers
Buy software after it is developed

Users
Experts on how current system works (most useful
features, features that need improvement)
Need to understand particular needs of special groups
(differently-abled individuals, persons unfamiliar with
16
computers, expert users)

Stakeholders in Requirements
Elicitation Process
Lawyers/auditors

Domain experts
Familiar with the problem that software must automate
(financial expert for a financial package, meteorologist
for software to model weather)
Also know about kinds of environment to which
product will be exposed

Familiar with government, safety or legal requirements

(tax expert ensures payroll package adheres to tax law,
experts on standards which are relevant to products
functions)

Software Engineers/other technology experts

Ensures that the product is technically and
economically feasible
Educate customer about innovative technology,
recommend new functionality taking advantage of these
technologies, and can estimate cost and development
time

Market Researchers
Conduct surveys to determine future trends and
potential customers needs
17

18

19

20

Techniques for Eliciting Requirements

Techniques for Eliciting Requirements

Interviewing stakeholders

1. Interviewing stakeholders

To capture the many views of the system and how it should

work

2. Reviewing available documentation

Reviewing available documentation

3. Observing current system (if one exists)

Documented procedures of manual tasks

Specifications or user manuals of automated system

4. Apprenticing with users

5. Interviewing users/stakeholders in groups

Observing current system (if one exists)

Gather objective information about how users perform their
tasks
Better understand the system that the developers are about to
automate or change

6. Using Domain-specific strategies

7. Brainstorming
21

Techniques for Eliciting Requirements

Apprenticing with users
Learn more about users tasks in more detail as the user
performs them

22

Types of Requirements Functional

Requirements
Describes a required behaviour in terms of
required activities

Interviewing users/stakeholders in groups

e.g. reactions to inputs, states of each entity before

and after an activity occurs

So that they will be inspired by one anothers ideas

Using domain-specific strategies

Defined boundaries of a solution space for our

problem

To ensure that stakeholders consider specific types of

requirements that are relevant to their particular situations

Brainstorming with current and potential users about how

to improve the proposed product
23

Solution space is the set of possible ways that

software can be designed to implement the
requirements

24

Types of Requirements Quality / NonFunctional Requirements

Make Requirements Testable

Make requirements testable so the conclusion
of whether or not a proposed solution meets
the requirement, must not vary according to
who is doing the evaluation

Describes some quality characteristic that

the software solution must posses
e.g. fast response time, ease of use, high
reliability and low maintenance costs

Design criteria that can be optimised and

used to choose among alternative
implementations of functional requirements

Fit criteria
Objective standards for judging whether a
proposed solution satisfies the requirements

25

Constraints on Requirements Design

Constraints
Design constraint
Design decision that has already been made and
that restricts the set of solutions to our problem

26

Requirements Problem - Conflict

May encounter conflicting ideas of what
requirements ought to be, when eliciting
from stakeholders

e.g. choice of platform or interface components

Possible solutions are

Process constraint

Ask customer to prioritise requirements

Negotiation

Restriction on the techniques or resources that

can be used to build the system
e.g. customer may insist that we use agile methods,
so that they can use early versions of the system
while we continue to add features
27

Conflict Solutions Customer

prioritises requirements

28

Conflict Solutions Negotiation

Requires skills, patience and experience in
finding mutually acceptable solutions

Helps customer reflect on which of requested

services and features are most essential
Loose prioritisation scheme separates requirements
into 3 categories

With effective negotiation, stakeholders will

understand and appreciate each others
fundamental needs and
strive for a resolution that satisfies everyone

Essential Requirements that absolutely must be met

Desirable Requirements that are highly desirable but
not necessary
Optional Requirements that are possible but could be
eliminated
29

30

Different Purposes of
Requirements
Requirements analysts
and their clients
Designers

Test team
Maintenance team

Requirements Documents
1. Requirements Definition

To explain their
understanding of how the
system would behave
Used as constraints on what
would be considered an
acceptable solution
To derive a suite of
acceptance tests
To help ensure that the
system enhancements do
not interfere with the
systems original intent

Aimed at a business audience, such as clients,

customers and users
Complete listing of everything customer wants to
achieve
Written entirely in terms of environment, describing
how the environment will be affected by the proposed
system

2. Requirements Specification

Aimed at a technical audience, such as designers,

testers and project managers
Restates requirements as a specification of how
proposed system will behave
Written entirely in terms of environment, except that
refers solely to environmental entities that are
accessible to the system via its interface

31

Characteristics of Requirements

Characteristics of Requirements
1.
2.
3.
4.
5.
6.
7.
8.

1. Correctness

Correctness
Consistency
Unambiguity
Completeness
Feasibility
Relevance
Testability
Traceability

Developer and customer should ensure conformity to

our understanding of the requirements

2. Consistency

No conflicting requirements, as inconsistent

requirements cannot be satisfied simultaneously

3. Unambiguity

Multiple readers of requirements should have

different but valid interpretations

33

Characteristics of Requirements

34

Characteristics of Requirements
5. Feasibility

4. Completeness

32

Set of requirements is defined as complete if it

specifies required behaviour and output for all
possible inputs in all possible states under all possible
constraints

Existence of a solution to customers need

6. Relevance

Indirectly related to customers need or may restrict

developers unnecessarily

7. Testability

Externally complete if all states, state changes,

inputs, products, and constraints are described by
some requirement

Internally complete if there are no undefined terms

among the requirements

Existence acceptance tests that would clearly

demonstrate whether the eventual product meets the
requirements

8. Traceability

35

Organisation of requirements for easy reference

There should be correspondence between every entry
in the requirement definition and requirements
36
specification, and vice versa

Purpose of characteristics

Purpose of characteristics

Help in making the decision when we have

collected enough information

The degree to which we want to satisfy these

characteristics will affect:
Type of information that we gather during
requirements elicitation, and how comprehensive we
want to be

Also when we need to learn more about

what a particular requirement means

Specification language we choose to express the

requirements and the validation and verification
checks that we eventually perform to assess the
requirements
37

38

40

39

41

42

43

44

45

46

47

48

49

50

51

52

53

54

Questions
What are crucial process steps of requirement
engineering ? Discuss with the help of a diagram
What do you understand with the term
requirements elicitation?
What are components of a use case diagram.
Explain their usage with the help of an example
Draw the ER diagram for a hotel reception desk
management
56

55

End of Lesson III

Some examples of E-R Diagrams

SPARE MANAGEMENT DATA FLOW
DATABASE

ADD INVENTORY

Thank you

ADD FAULTY

ADD RMA NO.

DAMAGED INVENTORY

ADD SITE ID

SHIPPED INVENTORY

REMOVED INVENTORY

CURRENT INVENTORY

INVENTORY ANALYSIS

TRENDING
USER INTERFACE

57

SITE MANAGEMENT

SPARE MANAGEMENT
DATABASE

ACTIVE WORKS

PRE-SUBMISSION

USER INTERFACE
PLANNED WORKS

SUPPORT ENGINEERS

COMPLETED WORKS

PLANNED WORKS

Diagram 3

58

Let us do one E-R diagram for

Grade Sheet building

ACTIVE OUTAGE

C
U
S
T
O
M
E
R
A
R
E
A

PRE-SUBMISSION

OUTAGE REPORT

SUPPORT ENGINEERS

RESTORED OUTAGES

OUTAGE REPORTING

FAULT MANAGEMENT DATA FLOW

59

60

10

Grade Sheet Building

Grade Sheet Building

SRS

What are the entities in a Grade Sheet?

Interviews/ Questions/ Requirement Analysis

Scope and Specifications

ID
Name
Semester Details with Year and Month
List of Courses
Grades obtained
CGPA for that semester

What a Grade Sheet will have now?

Student ID?
Name?
Is Grade Sheet for a specific semester? Or for whole program,
showing the history of all courses in all semesters of a specific
student?
Is there any change in the Grading Scheme over the time ?
Is there any change in the course codes and course titles?

61

Grade Sheet Building

62

Grade Sheet Building

Do we need the Teacher Information?

What are the entities in a Grade Sheet?

What is a Faculty?
Who offer the courses? And to who?
What is a class?
Do all the students in a class belong to one faculty?
Do we need to know the answers for the above?
If a student gets F grade and then repeats the same course
and gets another grade now; how that information should
be reflected?

ID
Name
Semester Details with Year and Month
List of Courses
Grades obtained
CGPA for that semester

63

Grade Sheet Building

64

Grade Sheet Building

What Functions we do need?
Structure for a student?
Structure for a teacher?
Adding a teacher/update/ removing
Similarly a student?
Similarly a course?

What are the Objects?

Student
Teacher
Course
Grade
Class
Faculty
65

How we determine the final mark?

How we determine the grade?
How CGPA is computed?

66

11

Grade Sheet Building

Grade Sheet Building

What Technologies do we use to develop

this application?

Develop DFDs
Develop E-R Diagrams

Who enter the marks? [Inputs?]

Who will see the grades? [outputs?]
Who will verify these ? [verification or
validation?]

Decide who does what?

Determine the Team Size
Determine the Time Frame for the project
67

68

12