ࡱ > Y LD bjbjWW , = = ; 9 ] 8 L ` X R h h (
V V V V : IV W W $ Y [ X u X h
V
V
* C V | " f ^ U R Requirements Analysis & Specification
What is it?
The first step in the development of any software system
Particularly important in the development of Large & Very Large software systems where the mental manageability skills of a single person are inadequate for the size of the task
The users' needs must be carefully identified and documented - an iterative process
Definition
Document describing the wants & needs of the clients/users
The Process
The phase is a WHAT phase rather than a HOW phase
'WHAT' questions are answered during this phase
WHAT are the users' needs?
WHAT is the current system, if there is one?
WHAT are the constraints on the current & future systems?
Resist the temptation to answer the HOW questions
Requirements are both functional
.describing function or service
and non-functional
describing system constraints such as time, money, platforms, etc.
The Result/Output of the Phase
is a Requirements Specification Document ( RSD )
It should reflect a mutual understanding between client & developer of the work to be completed and the various details surrounding that completion
The RSD provides the basis between client & developer and for compliance testing - did we develop the right system?
Contents
An RSD should be:
Unambiguous
No room for interpretation
Complete
All the components should be described
Verifiable
'Yes, this is what we want!'
Consistent
It shouldn't contradict itself
Modifiable
Adding future additions
Traceable
Backwards - where did the requirement come from
Forwards - through all future phases
Useable
Reference document to future phases
Requirement Analysis & Specification documents are read by different types of readers, therefore, the document should also be readable in different 'audience modes'
Requirements Analysis Definition
Client Managers
End Users
What the users' want
Client Engineers
Contractors
3rd Parties
Development Architects
Analysts
Designers
Requirements Specification Document
End Users
What the users' are to be given
Client Engineers
Development Architects
Designers
Developers
What needs implementing
Requirements Analysis & Specification has
4 Main Stages
Feasibility Study
Requirements Analysis
Requirements Definition
Requirements Specification
Stages are iterative
Feasibility Study
Evaluates the ability to satisfy:
a) identified user needs using the current software hardware & software technologies
b) the constraints of the users' organisation - including budgetary constraints
It may be that as part of the project, a new piece of hardware is developed
Requirements Analysis
Questions to be asked
who are the people involved and what are their backgrounds? ( user analysis )
what is the current system ( if there is one ), what equipment constraints exist and what are the functions to be incorporated? ( environmental analysis )
when must the system be completed and what are the various timetables for changing over to the new system - installation, testing, training, etc ( project management )
what is the anticipated impact in terms of personnel, training, etc.? ( organisational analysis )
why is the new system being developed? ( reasoning )
what are the constraints in terms of costs, etc?
Answers are gathered via interviews, observations, etc.
Assessment of system goals are also required - cut costs, reduce errors, etc.
The Requirements Specification should:
completely specify technical requirements
available equipment
new equipment required
specify constraints and functions
specify what should be done in exceptional cases
error processing in safety critical systems
specify performance requirements
Response times
Storage & compression
Requirements Specification should detail what the system will do ( again, notice WHAT rather than HOW ) and what the operational constraints are
The Requirements Specification Document should be:
understandable to client & developer ; &
the language/descriptions used should be suitable for both parties
agreed upon by the client and developer
'Yes, this is what we want!'
'Yes, we can do all this for you!'
It should:
state all functions to be performed
list the functionality to be provided
state all constraints that affect the system
provide testable criteria for acceptance
list qualities of the desired system ranked in terms of importance ( and how to measure them )
state the default conditions
what the system can expect as the norm
state error conditions & their resolution
The document may contain:
An introduction including general goals
Documentation of the current system
current physical
current logical
data dictionary
file structures
Documentation of the proposed system
proposed physical
proposed logical
functional specifications ( services to be provided )
data dictionary
file structures
non-functional requirements ( constraints )
feasibility ( including estimates of time, money & personnel )
system evolution assumptions ( anticipated changes and their resolutions )
Glossary
List of terms used with an explanation of what they mean
Customer sign-off
Actual space for client to sign printed copy
Preliminary user manual
Screen shots
System Admin Guide
The RSD should specify:
the external system behaviour
remember WHAT not HOW
the constraints on the implementation
It should be easy to change & serve as a reference document during future phases
Acceptable responses to undesired events should be described
Preparing an RSD
A number of methodologies
Natural language is used for most of it
May be ambiguous & open to interpretation
More structured methods may be used for more complex parts - diagrams, etc.
Once the document is written, all parties should review it
Requirements Analysis
requirement
feature of system or system function used to fulfill systems purpose
focus on customer & problem, not solutions
requirements definition document (customer)
requirements specification document (programmer)
Types of Requirements
functional requirements
implementation independent
inputs, outputs, process, error handling
non-function requirements (constraints)
implementation dependent
physical environment
interfaces
user & human factors
functionality
documentation
data
resources
security
quality assurance
Validation of Requirements?
correct?
consistent? (free from conflict)
complete?
externally - all desired properties are present
internally - no undefined references
realistic?
each requirement describes something needed by customer
verifiable? (testable)
traceable?
Requirements Definition Document
general purpose of system
system background & objectives
description of approach
detailed characteristics of proposed system (data & functionality)
system operating environment
F.A.S.T. (Facilitated Application Specification Technique)
problem definition
meeting between customers & developers at neutral site
rules for participation & preparation established
agenda suggested (brain storming)
facilitator appointed
definition mechanism (sheets, flip charts, wall boards, stickers)
goal is to identify problem, propose elements of solution, negotiate different approaches, specify preliminary set of requirements
QFP (Quality Function Deployment)
customer needs t e c h n i c a l r e q u i r e m e n t
n o r m a l r e q u i r e m e n t s ( m i n i m a l f u n c t i o n a l & p e r f o r m a n c e r e q u i r e m e n t s )
e x p e c t e d r e q u i r e m e n t s ( i m p o r t a n t & i m p l i c i t r e q u i r e m e n t s )
e x c i t i n g r e q u i r e m e n t s
F u n c t i o n a l D e p l o y m e n t ( V a l u e o f R e q u i r e d F u n c t i o n s )
I n f o r m a t i o n D e p l o y m e n t ( D a t a O b j e c t s P l a n n e d o r C o n s u m e d b y S y s t e m )
T a s k D e p l o y m e n t ( P r o d u c t B e h a v i o r O p e r a t i n g E n v i r o n m e n t )
V a l u e A n a l y s i s ( R e l a t i v e P r i o r i t i e s f o r R e q u i r e m e n t s )
c u s t o m e r i n t e r v i e w s
o b s e r v a t i o n
s u r v e y s
h i s t o r i c d a t a
C u s t o m e r V o i c e T a b l e
e x t r a c t s e x p e c t e d r e q u i r e m ents
derive exciting requirements
Analysis Principles
information domain of problem must be presented & understood
models depicting system information, function, and behaviors should be developed
models & problem must be partitioned in manner that uncovers detail in layers
analysis proceeds from essential information toward implementation detail
Specification Principles
separate functionality from implementation
a process-oriented specification language is needed
specification must encompass system containing the software component
specification encompasses system environment
system specification = cognitive model
specification must be operational
specification must be tolerant of incompleteness & easy to add to
specification must be localized & loosely coupled
Requirements Review
goals & objects review
compare requirements to goals & objectives
consider system operating environment
assess & document all risks in system development operation
discuss testing procedures
Evaluating Specification Techniques
requirements understandable to nave users
requirements for basis for design & testing
*automated requirements checking?
requirements form external view of system
technique aid in organizing and structuring requirements?
*tool for prototyping?
*automatic test case generation from requirements
appropriate for application?
Requirements Specification Methods
data modeling
data object tables are determined (attributes = fields)
object = [record]
normalization rules
given instance of data object, use one value for attribute?
attributes represent elementary items
when more than one attribute is used to identify object, they describe some "key"
all non-ID attributes represent some characteristic of instance name by key
E-R diagram (Entity-Relationship)
hierarchical data structure
HIPO chart (Hierarchy Input Output chart)
strength
show function
weakness
no mechanism for non-functional requirements
no checking mechanism
data flow diagrams (DFDs)
control flow diagrams (CFDs)
decision table
finite state machine
se t o f m a c h i n e s t a t e s , S
S 0 S , s t a r t s t a t e
F S , f i n a l s t a t e s
i n p u t s y m b o l s e
t r a n s i t i o n f u n c t i o n ( N O T A T I O N G O E S H E R E )
e v e n t t a b l e
v e r t i c a l a x i s s y s t e m m o d e s o r s t a t e s
h o r i z o n t a l a x i s e v e n t s
t a b l e e n t r i e s a c t i o n
P e t r i N e t
S t r u c t u r e d A n a l y s i s & Design Technique (SADT)
structured analysis
structured analysis activity diagram
structured analysis data diagram
design technique
explains how to interpret results of structured analysis (control issues)
structured system analysis
use data flow diagrams
use data dictionaries
pseudocode algorithms (control information)
relational data tables indicate data relations
requirements dictionary (a.k.a. data dictionary)
all system elements
dictionary format
name
alias
where used & how (producer & consumer relations)
content & description (notation for representation)
supplementary information
ERPP
risks / unknowns inspiring use
customer requirements
technology
interfaces
risks in using ERPP
premature delivery
premature design selection
features in prototype can get lost in final product
there is tendency to choose efficiency over modifiability
requirements analysis
what
when
cost
competition
reuse
risk
contingencies
rewards
design
conversion of requirements into algorithms & data structures
im p l e m e n t a t i o n & t e s t i n g
c o d e / t e s t / d e b u g
f i n a l s p i n c y c l e
e a c h m o d u l e i s e v a l u a t e d
l e a v e a s i s
r e w r i t t e n
r e p l a c e d w i t h e x i s t i n g c o d e
d i s c a r d e d a s n o l o n g e r n e e d e d
r e i m p l e m e n t a t i o n s y m p t o m s
p r o t o t y p e s p a g h e t t i c o d e
* p r o t o t y p e c a n n o t b e e x t e n d e d t o m e e t f u l l u s e r r e q u i r e m e n t s
w o r k t o f i x w o r k t o s t a r t a g a i n
S o f t w a r e E n g i n e e r i n g
R e q u i r e m e n t s A n a l y s i s
S t a t i n g p r o b l e m t o b e s o l v e d & r e q u i r e m e n t s w h i c h e x i s t t h a t d e f i n e a s u c c e s s f u l s o l u t i o n t o t h e p r o b l e m
S p e c i f i c a t i o n
C o m p l e t e s p e c i f i c a t i o n o f t h e technical requirements for the system including precisely what system is supposed to do and the operational constraints
Often serves as a performance contract between developer & customer
Results of this phase embodied in a requirements specification document
Important that this document communicates information clearly, accurately & completely
5 W & 1 H Questions
Who?
What?
When?
Where?
Why?
How?
Functional Requirements
Described by data-flow diagrams, activity specifications & data dictionary
Describe how system should behave given certain input
Non-functional Requirements
Requirements or restrictions posed by the customer or the problem
Do not relate directly to functions or operations to be performed by the system
Points to note when writing non-functional requirements:
Should be written so that they can be empirically verified once system is created
Avoid vague statements
For example,"system must respond quickly" - difficult to verify
Non-functional Requirements
Points to be Considered
User Interface & Human Factors
Documentation
Hardware Considerations
Performance Characteristics
Error Handling & Extreme Conditions
System Interfacing
Quality Issues
System Modifications
Physical Environment
Security Issues
Resources & Management Issues
Requirements Specification
Specifications should clearly, completely & consistently specify the technical requirements for the system, including software, hardware & manual components
Developing the Requirements Specification Document - 1
Check List
The document should be readily understandable by both the customer & the developer
The conditions stated in the document should be mutually agreeable to both developer & customer
The specification must precisely state all functions to be performed by the proposed system
Developing the Requirements Specification Document - 2
The specification must state all constraints which affect the proposed system
The document must provide testable criteria for acceptance of the system
The qualities of the desired system should be listed, together with their relative importance, and how these qualities will be measured or tested
Default & error conditions should be stated whenever necessary
Contents of the Requirements Specification Document - 1
General Goals
Provides a description of problem to be solved & the proposed solution
Should be written at a general, introductory level
For small systems, 1 to 2 pages sufficient
Description of Current System
using DFDs, process descriptions etc.
Description of Proposed System
using DFDs, process descriptions etc.
Contents of the Requirements Specification Document - 2
Glossary
Dictionary of words & terms used, along with definitions
Should include all words, phrases & abbreviations used in document which might not be known to readers of the document
Final Section
Contract between customer & developer
Summarises aspects of project such as deadlines, contractual obligations, etc.
Evaluating the Requirements Specification
Primary technique available is the review
Review
An evaluation of technical material by a group of people working together
Goal
To obtain accurate information concerning status and/or quality of the technical material
May be formal or informal
http://www.cs.clemson.edu/%7Ekjhay/CpSc472/Week1/index.htm
http://dragon.seowon.ac.kr/%7Eyklee/course_mtrl/method/slide/week2/index.htm
http://dragon.seowon.ac.kr/%7Eyklee/course_mtrl/method/slide/week3/index.htm
http://dragon.seowon.ac.kr/%7Eyklee/course_mtrl/method/slide/week5/index.htm
http://www2.ics.hawaii.edu/~johnson/413/lectures/5.2.html
Page PAGE 2
(Alex Fleming, 2001 Page PAGE 26
V X , 7 R C c + , 7 8 E F X! ! ! ! !
" " J" L" j" " " " " " ,# # # $$ 7$ ^% v% ' ' ' ' B) d) * * * * 8, :, `, b, , , - - - - . . . . ]0 a0 3 3 J4 L4 ~4 4 4 4 OJ QJ 0J OJ QJ 0J OJ QJ 5>*0J >*H* X & 2 k q | % @ m 2 u [ A & 2 k q | % @ m 2 u [ A L i t
ý{xrxlxfc`
"
E
o
:
I
%A L i t
A
B
# 8 I U a x
A
B
# 8 I U a x . Z h z
a
) ٬|vspjd^
'
k
D
$ . Z h z
a
) w Q 1 [ o ) w Q 1 [ o & 5 K 8 { 9 f 2 \ v {uolf`
s
T
}
a
B
z Y $ & 5 K 8 { 9 f 2 \ v v ( : K W a * H ^ # = e - yvpjgd
H
=
^
k
6br
Y
% ( : K W a * H ^ # = e - 9 5 Q {
& F
@&
& F @&
& F+ @&
& F @&
& F
p@&
& F+
& F, - 9 5 Q {
% 7 S \ } ü~qdWJGC<
~
V
_
i
n
|
+
+
+
\+
+
, % 7 S \ } ! 8 C d ~ P c
& F @&
& F+
& F @&
& F+ @&
& F @&
& F
@&
} ! 8 C d ~ P c F 0 ,! X! ! L" " .# X# zwuuqjc`] W
,
}
+
+
+
F 0 ,! X! ! L" " .# X# r# # # # $ $$ 8$ u$ $ %
& F @&
& F,
& F @&
& F+
& F @&
X# r# # # # $ $$ 8$ u$ $ % ^% w% % % & I& p& & & ' ' ' 3' ^' ' ' ' ' *( V( x( »yrkhd]V
,
,
,
,
,
% ^% w% % % & I& p& & & ' ' ' 3' ^' ' ' ' ' *( V( x( ( ( (
& F @&
& F @&
& F @&
& F @&
x( ( ( ( %) B) e) s) ) ) ) * 5* * * * + >+ G+ V+ _+ + + + + + yrkd]VOHA
+
+
+
+
+
+
7
0
V +
+
+
( %) B) e) s) ) ) ) * 5* * * * + >+ G+ V+ _+ + + + + + + 2,
& F+ @&
& F @&
& F+ @&
& F @&
& F @&
+ + 2, \, , , , - d- - - - . 0. U. v. . . . / / I/ y/ / / / / ǿxqjc\UND +
, +
+ +
* +
) +
( +
' +
&
+
% +
$ +
# +
" +
!
+
+
+
+
+
+
+
+
2, \, , , , - d- - - - . 0. U. v. . . . / / I/ y/ / / /
& F @&
& F+
& F @&
& F+ @& / / /
0 A0 [0 ]0 b0 0 0 0 0 0 0 0 &1 `1 v1 |1 1 1 1 1 1 1 1
& F @&
& F+
& F @ @&
/ /
0 A0 [0 ]0 b0 0 0 0 0 0 0 0 &1 `1 v1 |1 1 1 1 1 1 1 ƾ}ume]UME +
9 +
8 +
7 +
6 +
5 +
4 +
3 +
2
+
1 +
0 +
/ +
. +
- ~
1 1 1 1 02 Z2 |2 2 2 2 3 N3 3 3 24 v4 x4 z4 |4 ~4 4 4 5 5 5 5 z6 {6 6 7 »ynk`U /
D /
C .
B
+
A
+
@
+
?
+
> '+
= e+
< l+
; u+
: 1 1 1 02 Z2 |2 2 2 2 3 N3 3 3 24 v4 x4 z4 |4 ~4 4 4 5 5 5 5
& F @&
& F p@&
& F+ 4 5 5 5 5 {6 ]7 u7 7 18 28 M8 8 8 8 9 9 9 9 : ; ; ; ; = = > > @ @ A A B D D D D D D !D "D #D $D =D >D DD ED GD HD ID LD 6 j 60J mH
j 0J U0J 5CJ 5CJ 5CJ 5CJ 55CJ 25 z6 {6 6 7 ^7 v7 {7 7 7 7 7 7 7 7 18 28 N8 8 8 8 9 l9 9 9
& F4
& F3
& F2
& F1
& F0
& F/
& F. 7 ^7 v7 {7 7 7 7 7 7 7 7 18 28 N8 8 8 8 9 l9 9 9 9 9 ƻ~xmbWLF
4
S u3
R 3
Q m2
P
n 2
O 1
N
g 2
M 1
L 1
K 1
J 1
I 1
H 1
G 1
F 0
E 9 9 9 : %: =: Y: }: : : : : : : ; ; ; ; ; F< < = = := = = c> >
& F2
& F1
& F5 9 : %: =: Y: }: : : : : : : ; ; ; ; ; F< < = = := ɾysh]RGA
A2
c 2
b 2
a 1
`
H 1
_ 5
^ 5
] 5
\ $5
[ 35
Z F5
Y j5
X 5
W 5
V 5
U 5
T := = = c> > > > > 0? c? ? ? ? ? @ O@ X@ @ A A > > > 0? c? ? ? ? ? @ O@ X@ @ A A B LD % ' ) + - . 0 2 4 6 8 9 < > @ C E
) v - } X# x( + / 1 7 9 :=
_PID_GUID A N { 3 4 8 4 7 3 C 3 - D 3 B 3 - 1 1 D 5 - A B B 6 - 0 0 C 0 D F E A 7 7 2 4 }
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u w x y z { | } R o o t E n t r y F N%ؚ H3 1 T a b l e G \ W o r d D o c u m e n t , S u m m a r y I n f o r m a t i o n ( v D o c u m e n t S u m m a r y I n f o r m a t i o n 8 ~ C o m p O b j j O b j e c t P o o l H3 H3
F Microsoft Word Document
MSWordDoc Word.Document.8 9q