Requirements / Specifications

01/18/10 CS-499G 2

Requirements

Determine what the customer needs (wants) the software to do

What are requirements? An abstract statement of a needed service or system

constraint Requirements serve multiple functions

the contract for servicesthe basis for designthe basis for verification of the final product

01/18/10 CS-499G 3

Requirements Properties REQUIREMENTS MUST BE: Clearly defined in sufficient detail Flexible in form and content

{ functionally organized, cross referenced, indexed, with a table of contents }

Feasible Correct Consistent Testable

testing must be traceable to requirements Precise Understandable

{ by all who have to read them ) Organized Complete SO THAT: NOT OPEN TO INTERPRETATION

01/18/10 CS-499G 4

Complex Problems Many large software systems address complex problems Problems which are so complex that they can never be fully

understood Therefore, requirements are normally less than ideal

Reasons for inconsistency Large software systems must improve the current situation. It

is hard to anticipate the effects that the new system will have on the organization

Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements

System end-users and organizations who pay for the system have different requirements

Prototyping is often required to clarify requirements

01/18/10 CS-499G 5

The requirements document The requirements document is the official

statement of what is required of the system developers

Should include both a definition and a specification of requirements

It is NOT a design document. It should state WHAT the system should

do not HOW it should do it Attributes

Specify external system behavior Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the system

i.e. predict changes Characterize responses to unexpected events

01/18/10 CS-499G 6

Key points It is very difficult to formulate a complete

and consistent requirements specification Requirements may change as the project

develops, but ALWAYS GET APPROVAL FROM YOUR CUSTOMER FOR CHANGES IN THE REQUIREMENTS

The requirements document is a description for both customers and developers

Requirements errors are usually very expensive to correct after system delivery

Reviews involving the customer, management, and developers are used to validate the requirements

01/18/10 CS-499G 7

Requirements Analysis

Understanding the customer’s requirements for a software system

01/18/10 CS-499G 8

Problems of requirements analysis

Stakeholders don’t know what they really want Stakeholders express requirements in their own

terms Different stakeholders may have conflicting

requirements Organizational and political factors may influence

the system requirements The requirements change during the analysis

process. New stakeholders may emerge

01/18/10 CS-499G 9

Problems Seen with Requirements

Terms/tools that customer or ordinary reader may be unfamiliar with (provide definitions or links if necessary)

Vague/imprecise statements (“fast”, “easy to use”)

Promising more than can be delivered in a semester (prioritize functions, agree on essential functions to be delivered)

Make clear what platforms/environments will be supported (prioritize if needed)

Make sure customer understands and agrees to requirements