Presentation is loading. Please wait.

Presentation is loading. Please wait.

Www.ddss.arch.tue.nl 7M822 Software Requirements Introduction 7 September 2010.

Similar presentations


Presentation on theme: "Www.ddss.arch.tue.nl 7M822 Software Requirements Introduction 7 September 2010."— Presentation transcript:

1 www.ddss.arch.tue.nl 7M822 Software Requirements Introduction 7 September 2010

2 www.ddss.arch.tue.nl 7M822 Requirements engineering Get a complete description of the problem –feasibility study Process of establishing the services that the customer requires from a system –elicitation –specification –validation

3 www.ddss.arch.tue.nl 7M822 Domain analysis The process by which you learn about the domain to better understand the problem –The domain is the general field of business or technology in which the clients will use the software Benefits of performing domain analysis –Faster development –Better system –Anticipation of extensions

4 www.ddss.arch.tue.nl 7M822 Starting point for software projects AB CD New development Evolution of existing system Requirements must be determined Clients have Produced requirements

5 www.ddss.arch.tue.nl 7M822 Defining the problem A problem can be expressed as –A difficulty the users or customers are facing –Or as an opportunity that will result in some benefit

6 www.ddss.arch.tue.nl 7M822 Defining the scope Narrow the scope by defining a more precise problem List all the things you might imagine the system doing –Exclude some of these things if too broad –Determine high-level goals if too narrow

7 www.ddss.arch.tue.nl 7M822 Question ? Narrow the scope of a university registration system browsing courses registering fee payment room allocation exam scheduling

8 www.ddss.arch.tue.nl 7M822 What is a requirement? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification –Short and precise piece of information –Says something about the system –All the stakeholders have agreed that it is valid –It helps solve the customer’s problem

9 www.ddss.arch.tue.nl 7M822 Types of requirements 1 User requirements –Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements –A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification –A detailed software description which can serve as a basis for a design or implementation. Written for developers

10 www.ddss.arch.tue.nl 7M822 Types of requirements 2 Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development

11 www.ddss.arch.tue.nl 7M822 Functional requirements Describe functionality or system services Depend on the type of software, expected users and the type of system where the software is used Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

12 www.ddss.arch.tue.nl 7M822 Non-functional classifications Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. -Product requirements -Organisational requirements -External requirements

13 www.ddss.arch.tue.nl 7M822 Gathering and analyzing requirements Observation –Read documents and discuss with users –Shadowing important users doing their work –Session videotaping Interviewing –Specific details –Alternative ideas –Other sources of information –Draw diagrams

14 www.ddss.arch.tue.nl 7M822 Requirements and design In principle, requirements should state what the system should do and the design should describe how it does this In practice, requirements and design are inseparable

15 www.ddss.arch.tue.nl 7M822 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. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

16 www.ddss.arch.tue.nl 7M822 References Sommerville, Ian (2001) Software Engineering, 6 th edition http://www.software-engin.com Timothy Lethbridge & Robert Laganière (2005) Object-Oriented Software Engineering, 2 nd edition http://www.lloseng.com


Download ppt "Www.ddss.arch.tue.nl 7M822 Software Requirements Introduction 7 September 2010."

Similar presentations


Ads by Google