7M822 Software Requirements Introduction 7 September 2010

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

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

7M822 Starting point for software projects AB CD New development Evolution of existing system Requirements must be determined Clients have Produced requirements

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

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

7M822 Question ? Narrow the scope of a university registration system browsing courses registering fee payment room allocation exam scheduling

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

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

7M822 Types of requirements 2 Functional requirements Describe what the system should do Non-functional requirements Constraints that must be adhered to during development

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.

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

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

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

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

7M822 References Sommerville, Ian (2001) Software Engineering, 6 th edition Timothy Lethbridge & Robert Laganière (2005) Object-Oriented Software Engineering, 2 nd edition