Some Sub-Activities within Requirements Engineering
1.
2.
3.
4.
5.
Prototyping
Requirements Documentation
Requirements Validation
Requirements Measurements
Requirements Specification Technique and
Choosing a Specification Method
(1) “Requirements” Prototyping
• Software Prototyping is used for a variety of reasons :
1.
2.
3.
4.
help elicit requirements
understand and drill down on the requirements
validate the requirements
demonstrate feasibility
• There are two major categories of “general” software
prototyping:
– Throw-away prototyping : exploratory and code is not kept
as part of the final system
– Evolutionary prototyping : forms the basis of the final system
and code is kept as part of the final system
Prototyping: sub-process/procedure
Set Objectives
of Prototyping
Get the Resources
for Prototyping
Construct the
Prototype
Evaluate &
Document result
- elicit requirements
- understand reqs.
- demonstrate feas.
- etc.
- Evolutionary
- Throwaway
- customers/users
- developers
- analysts
- consultants
- hardware
- software
- etc.
- schedule
- cost
- document
- evaluate
- store results
- store prototype
Prototyping
• Most “successful & popular” prototyping have
been in the UI area :
– Terminal/Screen Interface:
• screen looks : field positions, color, size, shapes, etc.
• navigation : logical flow; consistency, etc.
• usage-aids : help text, default values, default choices, etc.
– Report /Document/Query Interface :
• looks : layout, titles and headings, fonts, diagrams, etc.
• usage : complete, consistency, etc.
• Feasibility Prototyping is the next most
popular:
– New Technology
– Performance (response time, through-put, etc.)
Broader Prototyping Role
• Many times prototyping is extended into solution design:
– feasibility of new technology
– performance trade off
– UI trade-off
• Prototyping, because it demonstrates a potential solution,
allows the modification of requirements and active exchanges
of ideas even after requirements has been signed off.
• One danger is customers and management mistaking
prototypes with final solutions (especially with respect to
wanting aggressive schedule!)
(2) Requirements Documentation
• Requirements collected and prototyped must be
documented (text author advocates):
– Requirements document (in user customer terms)
• Contains more customer goals and current environment
information
– Requirements specification (for developers)
• Contains more details about data, systems interface, functional logic
But we usually do not have the luxury of 2 documents, but have
one running document that contains all the information.
IEEE/ANSI 830-1993
Requirements document structure of IEEE/ANSI 830
• Introduction
–
–
–
–
–
1.1 Purpose of requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
• 2. General description
–
–
–
–
–
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
• 3. Specific requirements
–
Covering detailed functional, non-functional and interface requirements.
• 4. Appendices
• 5. Index
IEEE Requirements Section 3 (cont.)
• 3.0 Specific Requirements
– 3.1 External Interface Requirements
•
•
•
•
User Interface
Hardware Interface
Software Interface
Communications Interface
– 3.2 Functional Requirements
• Function 1
• Function 2
•
.
•
.
•
.
–
–
–
–
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
(3) Requirements Validation & Verification
• Importance of Requirements Validation:
1.
2.
ensures that both the “customer/user” and the “developers”
understand and agree on the goals, the objectives, and the
characteristics ( both functional and non-functional) of the
final system
any error found here is cheaper to fix than at later stages of
the development process
• Some common validation techniques:
– manual review of requirements definition and specification
documents
– prototyping
Incidentally, requirements may also be negotiated !
Because in “real” world, most likely, there is only one requirements document
--- we won’t talk about verification (“proper evolution”) here.
Requirements Review
• We are looking for (correctness, completeness,
consistency, clarity, traceability and testability )
in:
– characterization of functions
– characterizations of the non-functions
• performance
• reliability, security, and accessibility
– characterization of data
– characterization of application, business, and logical
flow
– characterization of user interface
– characterization of existing systems and related
constraints
Requirements Review
• Other topics to understand and/or agree on:
–
–
–
–
–
customer/user domain or business environment
customer/user goals and objectives
customer/user expectations
customer/user priorities
customer/user background and training
• Will the system requirements that was just
reviewed satisfy the above set of topics ?
(4)
Some Measurements
• We construct metric and keep measurements so
that we can perform and manage better in the
future: (measurement is basic to “engineering”)
– number of requirements by type ---- impacts :
• sizing of work and cost estimation
• estimating schedule
– number of changes to requirements ----- indicates :
• stability of customer/user environment
• understanding of requirements by development
• completeness and consistency of initial requirements
– number of changes to requirements ----- influences:
•
•
•
•
number of defects in the final system
customer satisfaction
schedule and cost
development personnel morale and confidence
Measurements
• Measurements in numerical form allows:
–
–
–
–
counting
comparison
compute
Estimate
• Be careful of your :
– accuracy and reliability (consistency) of
measurements
– validity (applicability) of your measurements and
conclusions
Possible Measurement Dilemma
• Suppose you took two samples of development
organizations and asked them to review and
measure all the requirements “readiness”
(understand and have experience with) from 1 to
5 (with 1 been the best and 5 been worst)
– Group 1 came out with an “average” of 2.
– Group 2 came out with an “average” of 4.
• You may choose to go with the Group 1 that had a
self measurement of readiness at 2.
– But - - - what if the readiness for design and testing
activities for the two groups came out
reversed --- then what?
(need to consider “complete information)
(5) Requirements Definition & Specification
Techniques
• There are many techniques to choose from and more
are invented continuously.
• Some characteristics to look for:
– How difficult is it to use the technique? (the harder the
more likely you will make error)
– Is there a usage history?
– Is there any tool implemented for this technique?
– Is there any training material?
– Is it broadly accepted ? (especially by customers/users)
– Does it provide broad coverage of all types of requirements
(functions, data, UI, business flow, non-functions, existing
systems)