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 Requirementsor Requirement Spec Content

1. Functionalities

2. Information (Data)

3. User Interfaces (looks and navigation)

4. System & System Interfaces

5. Non-functional Constraints (security, perf., etc.)

6. 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)

RequirementsElicitation

RequirementsAnalysis

RequirementsDefinition/

Documentation

RequirementsPrototyping

RequirementsReview &Validation

RequirementsSpecification

Each Activity of the Process may have a Procedural description

clarify & negotiate

clarify & negotiate

Requirements Process Activities

• Requirements Elicitation:– Needs the participation of user and customer resources– May be improved with a pre-formatted questionnaire along with free-

formatted 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 :– 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.

multipleView-pts

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• 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 ! ****

often forgotten

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• what documents

• what modules

• what test cases

• etc.

2. Defining the rules of how the materials should be managed• 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

3. 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”