14603_srs complete (1)
Post on 04-Apr-2018
215 Views
Preview:
TRANSCRIPT
-
7/29/2019 14603_srs Complete (1)
1/53
1
Requirements Analysis and
Specification
-
7/29/2019 14603_srs Complete (1)
2/53
2
Organization of this
Lecture
Brief review of previous lecturesIntroduction
Requirements analysisRequirements specificationSRS documentSummary
-
7/29/2019 14603_srs Complete (1)
3/53
3
Requirements Analysis and
Specification
Many projects fail:
because they start implementing
the system:without determining whether
they are building what the
customer really wants.
-
7/29/2019 14603_srs Complete (1)
4/53
4
Requirements Analysis and
Specification
It is important to learn:
requirements analysis andspecification techniques thoroughly.
-
7/29/2019 14603_srs Complete (1)
5/53
5
Requirements Analysis and
Specification
Goals of requirements analysis andspecification phase:
fully understand the user
requirements
remove inconsistencies, anomalies,etc. from requirements
document requirements properly inan SRS document
-
7/29/2019 14603_srs Complete (1)
6/53
6
Requirements Analysis and
Specification
Consists of two distinctactivities:
Requirements Gatheringand Analysis
Specification
-
7/29/2019 14603_srs Complete (1)
7/53
7
Requirements Analysis and
Specification
The person who undertakesrequirements analysis and specification:
known as systems analyst:
collects data pertaining to the product
analyzes collected data:
to understand what exactly needs to be
done.
writes the Software RequirementsSpecification (SRS) document.
-
7/29/2019 14603_srs Complete (1)
8/53
8
Requirements Analysis and
Specification
Final output of this phase:Software Requirements
Specification (SRS)Document.
The SRS document is reviewedby the customer.reviewed SRS document forms
the basis of all futuredevelopment activities.
-
7/29/2019 14603_srs Complete (1)
9/53
9
Requirements Analysis
Requirements analysisconsists of two main
activities:Requirements gathering
Analysis of the gatheredrequirements
-
7/29/2019 14603_srs Complete (1)
10/53
10
Requirements Analysis
Analyst gathers requirementsthrough:
observation of existing systems,studying existing procedures,
discussion with the customer and
end-users,analysis of what needs to be
done, etc.
-
7/29/2019 14603_srs Complete (1)
11/53
11
Requirements Gathering
If the project is to automate someexisting procedures
e.g., automating existing manualaccounting activities,
the task of the system analyst is alittle easier
analyst can immediately obtain:
input and output formats
accurate details of the operational
procedures
-
7/29/2019 14603_srs Complete (1)
12/53
12
Requirements Gathering(CONT.)
In the absence of a workingsystem,
lot of imagination and creativityare required.
Interacting with the customer to
gather relevant data:requires a lot of experience.
-
7/29/2019 14603_srs Complete (1)
13/53
13
Requirements Gathering(CONT.)
Some desirable attributes ofa good system analyst:
Good interaction skills,imagination and creativity,
experience.
-
7/29/2019 14603_srs Complete (1)
14/53
14
Analysis of the Gathered
Requirements
After gathering all the requirements:
analyze it:
Clearly understand the user requirements,Detect inconsistencies, ambiguities, and
incompleteness.
Incompleteness and inconsistencies:resolved through further discussions
with the end-users and the customers.
-
7/29/2019 14603_srs Complete (1)
15/53
15
Inconsistent requirement
Some part of the requirement:
contradicts with some other part.
Example:One customer says turn off heater
and open water shower when
temperature > 100 CAnother customer says turn off
heater and turn ON cooler whentemperature > 100 C
-
7/29/2019 14603_srs Complete (1)
16/53
16
Incomplete requirement
Some requirements have beenomitted:
due to oversight.Example:The analyst has not recorded:
when temperature falls below 90 Cheater should be turned ON
water shower turned OFF.
-
7/29/2019 14603_srs Complete (1)
17/53
17
Analysis of the Gathered
Requirements (CONT.)
Requirements analysis involves:
obtaining a clear, in-depth
understanding of the product tobe developed,
remove all ambiguities and
inconsistencies from the initialcustomer perception of theproblem.
-
7/29/2019 14603_srs Complete (1)
18/53
18
Analysis of the Gathered
Requirements (CONT.)
It is quite difficult to obtain:
a clear, in-depth understandingof the problem:
especially if there is no working
model of the problem.
-
7/29/2019 14603_srs Complete (1)
19/53
19
Analysis of the Gathered
Requirements (CONT.)
Experienced analysts takeconsiderable time:
to understand the exactrequirements the customer has inhis mind.
-
7/29/2019 14603_srs Complete (1)
20/53
20
Analysis of the Gathered
Requirements (CONT.)
Experienced systems analystsknow -
often as a result of painfulexperiences ---
without a clear understanding ofthe problem, it is impossible todevelop a satisfactory system.
-
7/29/2019 14603_srs Complete (1)
21/53
21
Analysis of the Gathered
Requirements(CONT.)
Several things about the project shouldbe clearly understood by the analyst:
What is the problem?
Why is it important to solve the problem?What are the possible solutions to the
problem?
What complexities might arise while solvingthe problem?
-
7/29/2019 14603_srs Complete (1)
22/53
22
Analysis of the Gathered
Requirements(CONT.)
Some anomalies and inconsistenciescan be very subtle:
escape even most experienced eyes.
If a formal model of the system isconstructed,
many of the subtle anomalies and
inconsistencies get detected.
-
7/29/2019 14603_srs Complete (1)
23/53
23
Analysis of the Gathered
Requirements(CONT.)
After collecting all data regardingthe system to be developed,
remove all inconsistencies andanomalies from the requirements,
systematically organize requirementsinto a Software Requirements
Specification (SRS) document.
-
7/29/2019 14603_srs Complete (1)
24/53
24
Software Requirements
Specification
Main aim of requirementsspecification:
systematically organize therequirements arrived during
requirements analysisdocument requirements properly.
-
7/29/2019 14603_srs Complete (1)
25/53
25
Software Requirements
Specification
The SRS document is useful invarious contexts:
statement of user needs
contract document
reference documentdefinition for implementation
-
7/29/2019 14603_srs Complete (1)
26/53
26
Software Requirements Specification: A
Contract Document
Requirements document is areference document.
SRS document is a contractbetween the development team andthe customer.
Once the SRS document is approvedby the customer,
any subsequent controversies are settledby referring the SRS document.
-
7/29/2019 14603_srs Complete (1)
27/53
27
Software Requirements Specification:
A Contract Document
Once customer agrees to the SRSdocument:
development team starts to develop theproduct according to the requirementsrecorded in the SRS document.
The final product will be acceptable to thecustomer:
as long as it satisfies all the requirementsrecorded in the SRS document.
-
7/29/2019 14603_srs Complete (1)
28/53
28
SRS Document (CONT.)
The SRS document is known as black-boxspecification:
the system is considered as a black boxwhose internal details are not known.
only its visible external (i.e. input/output)behavior is documented.
SInput Data Output Data
-
7/29/2019 14603_srs Complete (1)
29/53
29
SRS Document (CONT.)
SRS document concentrates on:
what needs to be done
carefully avoids the solution (how to do)aspects.
The SRS document serves as a contract
between development team and thecustomer.
Should be carefully written
-
7/29/2019 14603_srs Complete (1)
30/53
30
SRS Document (CONT.)
The requirements at this stage:
written using end-userterminology.
If necessary:
later a formal requirementspecification may be developed fromit.
-
7/29/2019 14603_srs Complete (1)
31/53
31
Properties of a goodSRS
document
It should be conciseand at the same time should not be
ambiguous.
It should specify what the system must doand not say how to do it.
Easy to change.,i.e. it should be well-structured.
It should be consistent.It should be complete.
P ti f d SRS
-
7/29/2019 14603_srs Complete (1)
32/53
32
Properties of a goodSRS
document (cont...)
It should be traceableyou should be able to trace which part of the
specification corresponds to which part of thedesign and code, etc and vice versa.
It should be verifiablee.g. system should be user friendly is not verifiable
-
7/29/2019 14603_srs Complete (1)
33/53
33
SRS Document (CONT.)
SRS document, normallycontains three important parts:
functional requirements,
nonfunctional requirements,
constraints on the system.
-
7/29/2019 14603_srs Complete (1)
34/53
34
SRS Document (CONT.)
It is desirable to consider everysystem:
performing a set of functions {fi}.
Each function fi considered as:
transforming a set of input data tocorresponding output data.
Input Data Output Data
fi
-
7/29/2019 14603_srs Complete (1)
35/53
35
Example: Functional
Requirement
F1: Search BookInput:
an authors name:
Output:
details of the authors books and thelocations of these books in the library.
Author Name Book Details
f1
-
7/29/2019 14603_srs Complete (1)
36/53
36
Functional Requirements
Functional requirementsdescribe:A set of high-level requirementsEach high-level requirement:takes in some data from the useroutputs some data to the user
Each high-level requirement:might consist of a set ofidentifiable functions
-
7/29/2019 14603_srs Complete (1)
37/53
37
Functional Requirements
For each high-level requirement:
every function is described in terms
ofinput data set
output data set
processing required to obtain theoutput data set from the input dataset
N f ti l
-
7/29/2019 14603_srs Complete (1)
38/53
38
Nonfunctional
Requirements
Characteristics of the systemwhich can not be expressed asfunctions:
maintainability,
portability,
usability, etc.
N f ti l
-
7/29/2019 14603_srs Complete (1)
39/53
39
Nonfunctional
Requirements
Nonfunctional requirements include:
reliability issues,
performance issues,human-computer interface issues,
Interface with other external systems,
security, maintainability, etc.
-
7/29/2019 14603_srs Complete (1)
40/53
40
Constraints
Constraints describe things that thesystem should or should not do.
For example,
standards compliance
how fast the system can produce results
so that it does not overload another
system to which it supplies data, etc.
-
7/29/2019 14603_srs Complete (1)
41/53
41
Examples of constraints
Hardware to be used,Operating systemor DBMS to be used
Capabilities of I/O devicesStandards complianceData representationsby the interfaced system
-
7/29/2019 14603_srs Complete (1)
42/53
42
Organization of the SRS
Document
Introduction.
Functional Requirements
Nonfunctional RequirementsExternal interface requirements
Performance requirements
Constraints
-
7/29/2019 14603_srs Complete (1)
43/53
43
Example Functional
Requirements
List all functional requirementswith proper numbering.Req. 1:Once the user selects the search
option,he is asked to enter the key words.
The system should output details of allbooks
whose title or author name matches any ofthe key words entered.Details include: Title, Author Name,
Publisher name, Year of Publication, ISBNNumber, Catalog Number, Location in the
Library.
-
7/29/2019 14603_srs Complete (1)
44/53
44
Example Functional Requirements
Req. 2:When the renew option is selected,the user is asked to enter his
membership number and password.After password validation,the list of the books borrowed by him
are displayed.
The user can renew any of the books:by clicking in the corresponding renew
box.
-
7/29/2019 14603_srs Complete (1)
45/53
45
Req. 1:
R.1.1:Input:search option,Output: user prompted to enter the key words.
R1.2:
Input: key wordsOutput: Details of all books whose title or author
name matches any of the key words.Details include: Title, Author Name, Publisher name, Year
of Publication, ISBN Number, Catalog Number, Location in
the Library.Processing: Search the book list for the keywords
-
7/29/2019 14603_srs Complete (1)
46/53
46
Req. 2:
R2.1:Input:renew option selected,Output: userprompted to enter his
membership number and password.R2.2:Input: membership number and passwordOutput:list of the books borrowed by userare
displayed. User prompted to enter books to berenewed or
userinformed about bad passwordProcessing: Password validation,search
books issued to the user from borrower listand display.
-
7/29/2019 14603_srs Complete (1)
47/53
47
Req. 2:
R2.3:
Input: user choice for renewal of the
books issued to him through mouseclicks in the corresponding renew box.
Output: Confirmation of the books
renewedProcessing: Renew the books selected
by the in the borrower list.
E l f B d SRS
-
7/29/2019 14603_srs Complete (1)
48/53
48
Examples of Bad SRS
Documents
Unstructured Specifications:Narrative essay --- one of the worst
types of specification document:
Difficult to change,
difficult to be precise,
difficult to be unambiguous,
scope for contradictions, etc.
E amples of Bad SRS
-
7/29/2019 14603_srs Complete (1)
49/53
49
Examples of Bad SRS
Documents
Noise:Presence of text containing information
irrelevant to the problem.
Silence:aspects important to proper solution of the
problem are omitted.
Examples of Bad SRS
-
7/29/2019 14603_srs Complete (1)
50/53
50
Examples of Bad SRS
Documents
Overspecification:
Addressing how to aspects
For example, Library member names shouldbe stored in a sorted descending order
Overspecification restricts the solution spacefor the designer.
Contradictions:Contradictions might arise
if the same thing described at several places indifferent ways.
E l f B d SRS
-
7/29/2019 14603_srs Complete (1)
51/53
51
Examples of Bad SRS
Documents
Ambiguity:Literary expressions
Unquantifiable aspects, e.g. good user
interfaceForward References:
References to aspects of problem
defined only later on in the text.
Wishful Thinking:
Descriptions of aspects
for which realistic solutions will be hard to find.
-
7/29/2019 14603_srs Complete (1)
52/53
52
Summary
Requirements analysis andspecification
an important phase of software
development:
any error in this phase would affectall subsequent phases of
development.
Consists of two different activities:
Requirements gathering and analysis
-
7/29/2019 14603_srs Complete (1)
53/53
SummaryThe aims of requirements analysis:Gather all user requirements
Clearly understand exact user requirements
Remove inconsistencies andincompleteness.
The goal of specification:
systematically organize requirementsdocument the requirements in an SRS
document.
top related