Upload
wanya64
View
233
Download
1
Embed Size (px)
Citation preview
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