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
