Requirements
• A requirement is an “expression or a
description” of desired behaviors of :
–
–
–
–
A person
A software system (software system requirement)
A tool
etc.
Requirements Specification
• What is a requirement specification ?
– From Customer view : a description of WHAT the
customer needs “and/or” wants the system to perform
and behave to achieve the customer’s goals.
– From the Builder view: A description of WHAT the
system is capable of performing and behaving to fulfill
the goals (needs and wants) stated by the customers.
– These two should be very close or same ;
unfortunately, many times they are not. (Even the
above statements are slightly different.)
Importance of Requirements
• It may be obvious that requirements are important --- but how important?
• *Chaos Report’s list of top 5 factors of software
project failure: (3 involves “requirements”)
–
–
–
–
–
Incomplete Requirements
Lack of User Involvement
Lack of Resources
Unrealistic Expectations
Lack of Executive Support
*You can search on-line for Chaos Report.
Who are the Contributors & Stakeholders in
Making Requirements Phase a Success?
• Clients who are paying for the system
• Clients who are going to use the system
• Consultants and domain experts who are industry
specialists
• Marketing and sales people who are also domain experts
• Lawyers and Regulators who are familiar with laws and
rules of the industry
• Software engineers and technology experts who needs to
ensure the feasibility of the meeting the requirements
• Managers who ensures qualified resources are
used/involved.
Types of Requirements
• Requirements may be Divided into 2 Major Groups:
– Functional :
• Describes the interactions between the needed system and the
environment and the results achieved based on the interaction.
(e.g. payroll checks must be processed bi-monthly for all regular
worker and each check should be processed - - - - - - -)
• Describes “how” the system will behave under certain stimuli - it is
still more on the what will the system do
(e.g. if there is no “address,” do not print the check and generate an
error message)
– Non-Functional:
• Describes the constraints and restrictions under which the system
must perform and behave.
(e.g. the system must run on both Linux operating environment and
MS Windows environment)
(e.g. pay roll runs must be completed within 8 elapsed hours)
Further Expansion on Types of Requirements
into 4 categories (your text p. 150)
• Functional Requirements
– Functional Features and Data related to the Functional Features
• Design Constraints
– Restriction on environment, equipment, tools, etc.
– Input/Output to and from other systems
– Users and privileges (usage and user interfaces)
• Process Constraints (usage & user domain)
– Type of people, tools, process needed to develop system
– Documentation and training
• Quality Requirements (or Non-Functional Requirements)
–
–
–
–
Performance
Security
Reliability
Etc.
(Tsui’s) Categories of Requirements
or Requirement Spec Content
1.
2.
3.
4.
5.
6.
Functionalities
Information (Data)
User Interfaces (looks and navigation)
System & System Interfaces
Non-functional Constraints (security, perf., etc.)
Business Flow
Categories of Requirements
• Functionality of the system: this is the most obvious
type, describing what the system is to do (e.g. send weekly
direct deposit payroll to the respective financial institutions).
• Data : this describes all the inputs and outputs along with the
acceptable formats (e.g. context sensitive help text at the field
level describes both the purpose and the legitimate data format
for that field with a default value displayed in the field); also
certain intermediate and long term storage of the data is
described
• User Interfaces : this includes both user interface: a)
looks and b) the navigational flow of screens. A description of
the different kinds of users may also be included here.
Types of Requirements (cont.)
• Non-Functional characteristics: this is a list of and the
descriptions of the constraints under which the system must function (e.g.
performance, reliability and quality, security levels, maintainability, etc.) along
with when the system needs to be ready and with what resources limitations
there may be (e.g. first prototype in 3 months with $150k)
• “Business” Processes Flow : this is a description of the business
environment and the business process / flow under which the system is to
operate (e.g. the hourly information for temporary workers’ payroll are
received from the weekly “time-cards” filled in by the temporary workers
every Friday) along with current people, organization, procedures, and other
resources.
• Systems and System Interface: this is a description of the overall
systems environment (e.g. physical network, operating system, database, etc.)
under which this system needs to operate and must interface with.
Requirements Specification (types)
• Requirements “Specification” can be stated as:
– Simple/Informal: one written page handed to us by a
customer (e.g. write me a program in Java that computes
the Fibanocci number for positive integers up to 1 million
in value; would like to have this program in 2 weeks from
today, etc.) Yes, but most likely needs more elaboration.
– Complex/Formal: business system Request for Proposal
(RFP) which is 100 pages in volume describing the major
functions, input data, report formats, etc. about the
system desired.
• BUT --- We will need to have a Requirements
Development Process, (a full one) for the complex
requirements.
Requirements Development Process
(High Level “Functional” View – altered from p.144)
clarify & negotiate
clarify & negotiate
Requirements
Elicitation
Requirements
Analysis
Requirements
Definition/
Documentation
Requirements
Prototyping
Requirements
Specification
Requirements
Review &
Validation
Each Activity of the Process may have a Procedural description
Requirements Process Activities
• Requirements Elicitation:
– Needs the participation of user and customer resources
– May be improved with a pre-formatted questionnaire along with freeformatted input section for the users and customers to fill
– May include interviews, asking for and reading existing documentation,
monitoring current business procedures, apprentice at the user site, etc.
• Requirements Analysis :
multiple
View-pts
– Studying the existing materials and business (at the customer/user sites)
– Understand the elicited information
– Organize the information: prioritizing, aggregate, decompose,
categorizing the information
– Verification of information: checking for accuracy, checking for
consistency, conflicts, and completeness (How would you check for these ?)
• Requirements Definition/Documentation :
– Write down the gathered and analyzed user needs and wants in such a
manner that the customer and the users understand --- do not use
technical acronyms without explanation; do not include design or
solutions.
Requirements Process Activities (cont.)
• Validation :
– Requirements Prototyping :
• Build a simulated system to show the users and customers what
you think they asked for (How much of the system should you
prototype -- just the UI ? Or the navigation also?)
• Elicit feedback and record both the soft suggestions and the solid
modifications
– Requirements Document Review :
• Conduct a review of the Requirements Definition Document along
with what was recorded from the prototype feedback with the
participation of customers, users, implementers
(designers/programmers), and testers. (You may do a bit of
negotiation during/after the review --- impure review.)
• Rework the document, correcting the errors and improving on
any needed clarifications.
• Conduct a follow-up review and solicit “approval or
concurrence,” especially from the customer and users.
Requirements Process Activities (cont.)
• Requirements Specification:
– Should explain how the system should behave
often
forgotten
• what the customers needs/wants
• what the functionality and characteristics of the resulting system are
• what to demonstrate(test) to show that the system delivered is what
was asked for by the customer
– Writing the Requirements which also includes more technical
information for the designers, coders, and testers (i.e. possibly
contain “conceptual” design).
– May conduct a review to ensure that in the transformation from
the Requirements Definition Document nothing was negatively
modified.
– Rework the Requirements Specification document as necessary
– Gain “concurrence sign off” from all parties, including the users
and customers (especially for large and complex system).
Note: Your text talks about 2 kinds of requirements doc: 1 for customers and 1 for developers.
*** That rarely happens in real world ! ****
A Note on Agile Process &Requirements
• The Agile Process such as XP or Scrum view requirements
process quite differently and may pose some challenges:
– Physically close to the user and collect the needed information (a bit
hard to do in global economy with large projects)
– Don’t necessarily need to document everything in a specification
– Review and Validation of requirements are performed incrementally
and dynamically with the user as the developer is designing and coding.
(what about the tester? --- does he/she get to utilize the customer/user
too?)
• How would inconsistent requirements be caught if there is no overall
specification document to organize and compare the details of the
requirements? ( potential problem for any incremental process)
Considerations in “Managing” Requirements
• To ensure the “quality” of requirements specification,
some specific characteristics of requirements should be
considered:
–
–
–
–
–
Validity, in terms correctness (via review)
Reliable, in terms of consistency (via analysis and review)
Clarity, in terms of unambiguity (via analysis)
Complete, in terms of coverage (via analysis and review)
Realistic and Relevant, in terms of priority
• Customer Needs
• Customer Desires
– Verifiable, in terms of evolving into design, code and test
cases
– Traceable, in terms of referencing & back tracking
Requirements Management Tools
• There are many tools available and helpful:
– Documentation : MS Word, Adobe Acrobat, Visio,
Rational UML, etc.
– Prototype : MS Visual Basic, MS FrontPage, Power
Point, PHP-PostgreSQL, etc.
– Requirements Management : Caliber-RM (Borland),
Requisite-Pro (IBM), Rhapsody (IBM), etc.
• Configuration Management should be considered as
an integral part of the overall-process for large and
complex project and it should be used starting with the
Requirements Gathering Process
– MS Source Safe
– IBM Clear Case
Configuration Management
•
Configuration Management includes :
1.
Defining of what materials should be managed
•
•
•
•
2.
Defining the rules of how the materials should be
managed
•
•
•
•
•
3.
what documents
what modules
what test cases
etc.
material typing and tagging rules
locking mechanism and access rules
rules for the classification of material
rules for versioning of material
rules for the promotion of material
Implementing & Enforcing the management of the
defined materials according to the defined rules
Requirements Management &
Configuration Management
• Two key problems exist with managing the
requirements:
– Scope Creep: there needs to be a well defined change management
procedure or the requirements will inevitably “change” and “grow”
beyond what the original estimates of cost and dates can handle.
– Traceability or Tractability : in order to ensure that each
requirement is implemented and tested, there needs to be a
mechanism that allows the accountability of such
• With proper Configuration Management both of
these problems may be resolved.
– Scope creep : “locking and accessing control” along with
proper “versioning” and “promotion” scheme
– Traceability : “typing and tagging rules” and “locking
and accessing control”