Version 2.0

CSC565SOFTWARE ENGINEERING -

LAB

UNDERSTANDING REQUIREMENTS

SOURCE OF REQUIREMENTS

Initial requirements come from the customer, through:

Documents (such as RFI,RFP), meetings, interviews, reports, etc

Advanced/Detail requirements come from the analysis, after studying:

Scope and priceFeasibility (technological – software, hardware; organizational, socialPrototypes

Final requirements are stabilized in an iterative process

REQUIREMENTS vs DESIGN

Requirements:What the system should doMore abstract

Design:How the system should do itMore detail

TYPES OF REQUIREMENTS

Functional RequirementsStatements of services that the system should provide, how the system should react to particular inputs and how the system should behave in particular situations

Non-Functional RequirementsConstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

FUNCTIONAL REQUIREMENTS

Describe functionality or system service Depend on the type of software, expected users and the type of system where the software is used Functional user requirements may be high-level statements of what the system should do; functional system requirements should describe the system services in detail

FUNCTIONAL REQUIREMENTS : EXAMPLE

The user shall be able to search either all of the initial set of databases or select a subset from itThe system shall provide appropriate viewers for the user to read documents in the document storeEvery order shall be allocated a unique identifier (ORDER ID) which the user shall be able to copy to the account's permanent storage area

NON-FUNCTIONAL REQUIREMENTS

Product RequirementsRequirements which specify that the delivered product must behave in a particular way, e.g. execution speed, reliability etc.

Organizational RequirementsRequirements which are a consequence of organisational policies and procedures, e.g. process standards used, implementation requirements etc.

External Requirements Requirements which arise from factors which are external to the system and its development process, e.g. interoperability requirements, legislative requirements etc.

NON-FUNCTIONAL REQUIREMENTS

THE RESPONSES…

Extensive requirements gathering and formalization in order to minimize chances of change later

“On the fly” requirements elicitation in close collaboration with users and customers

Planned but iterative. Understand what is and is not known now, and plan and adapt accordingly.

FREEZE REQUIREMENTS

Requirements are determined completely in an early phase of the project. They are then “frozen” and form a contractual agreement between the customer and the supplier Issues

Not always realistic Doesn’t support changing requirements May lead to more expensive or brittle system

ON-THE-FLY REQUIREMENTS

Since requirements will change, determine any requirement informally and then only right before it is about to be implemented Exemplified by agile development methods

XP – “User stories”Scrum – Prioritize the product backlog for each “sprint”

IssuesRequires dedication to a particular way of working Relies on skilled individuals Needs constant interaction with the “customer”Quality of the customer can make or break the project

BE FLEXIBLE…

Different projects have different needs:Scale Safety Complexity Cost-sensitivityMarket-driven (innovation)

CompareDigital camera Desktop char clientNuclear power station control systemDigital television studio

ALSO CONSIDER…The degree to which requirements can be determined and at what stage of the development processThe amount of effort that is cost-effectively put into gathering and documenting requirements (vs. benefits on terms of reliability and customer satisfaction)Notations that can be shared and understood – development teams, customers, marketing, managementNotations that mesh well with design and implementation activities

Thank You