Developing Requirements

1. Developing Requirements Before software can be designed , its requirements must be well understood. Before requirements can be expressed, the application domain must be similarly well understood.

2. Example Outline in one paragraph the information you would need to gather in order to perform domain analysis for the airline reservation system. Lecture3

3. Domain Analysis • The process by which a software engineer learns 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 • A domain expert is a person who has a deep knowledge of the domain • Benefits of performing domain analysis: • Faster development • Better system • Anticipation of extensions Lecture3

4. Defining the Problem and the Scope • A problem can be expressed as: • A difficulty the users or customers are facing, • Or as an opportunity that will result in some benefit such as improved productivity or sales • The solution to the problem normally will entail developing software • A good problem statement is short and succinct Lecture3

5. 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 Lecture3

6. Example • A university registration system Lecture3

7. Example Define the problem and scope for a system that handles university degree requirements and registrations • Fee payments and related accounting and billing • Applications for admission • Editing and querying the list of available courses, including their descriptions and lists of prerequisites • Editing and querying the requirements for obtaining a degree • Editing and querying the list of courses to be taught in a given semester • Scheduling the times that courses will be offered • Allocating courses or exams to rooms • Helping students determine which courses they could take by analyzing their degree requirements, the courses they have previously taken, their schedule, and their preferences • Registering students • Recording marks • Printing transcripts Lecture3

8. Example • You are asked to improve a data entry program used to enter a patient’s personal information when he or she is first admitted to a hospital. Admission clerks have to enter each new patient’s name, address, telephone number, and various other pieces of data. The customer tells you that the admissions clerks make an unacceptable number of mistakes that contaminate the database and cause administrative problems. You are told that the problem is lack of clarity in the user interface, which leads the clerks to put information in the wrong places. What, however, is the real problem and how might understanding this affect potential solutions? Lecture3

9. Example • This is the inverse of the last example. This time, you are told by the customer that the problem is, “ the data-entry system is not “high-tech” enough”. Hence you are asked to write a system that scans drivers’ licenses and other documents in order to enter a new patient’s name and address accurately and quickly. What mistake could you be making if you accept this problem statement and proceed to do exactly what the customer asks? Lecture3

10. What is a Requirement? • It is a statement describing either • 1) an aspect of what the proposed system must do, • or 2) a constraint on the system’s development • In either case it must contribute in some way towards adequately solving the customer’s problem • the set of requirements as a whole represents a negotiated agreement among the stakeholders • A collection of requirements is a requirements document Lecture3

11. Functional Requirements • What inputs the system should accept • What outputs the system should produce • What data the system should store that other systems might use • What computations the system should perform • The timing and synchronization of the above Lecture3

12. Requirements Document Each functional requirement is given in the following format: • Index: • Name: • Purpose: • Input parameters: • Action: • Output parameters: • Exceptions: • Remarks: • Cross-references: Lecture3

13. A Requirements Engineering Process • Requirement Engineering Process • The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process • Requirements identification • Requirements analysis • Requirements specification • Requirement validation • Needed for: complex, large, or critical problems Lecture3

14. Requirements problems • The requirements don’t reflect the real needs of the customer for the system. • Requirements are inconsistent and/or incomplete. • It is expensive to make changes to requirements after they have been agreed. • There are misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system Lecture3

15. RE process - inputs and outputs Lecture3

16. Stakeholders in the RE process • Stakeholders in a process are the people involved in the execution of that process • They are normally identified by their roles rather than individually • Requirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc) as well actors interested in the solution (system designers, etc.) Lecture3

17. Types of stakeholder • Software engineers responsible for system development • System end-users who will use the system after it has been delivered • Managers of system end-users who are responsible for their work • External regulators who check that the system meets its legal requirements • Domain experts who give essential background information about the system application domain Lecture3

18. Human and social factors • Requirements engineering processes are dominated by human, social and organizational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organizational goals. • System stakeholders may come from a range of technical and non-technical background and from different disciplines Lecture3

19. Factors influencing requirements • Personality and status of stakeholders • The personal goals of individuals within an organization • The degree of political influence of stakeholders within an organization Lecture3

20. Types of Requirement • 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 Lecture3

21. System requirements versus Software requirements • System requirements include constraints and capabilities of the entire product including hardware and software. • Software requirements form a subset of system requirements. • System requirements are mostly constrained by organizational policies and environment. • Software requirements may or may not be constrained by organizational policies. Lecture3

22. Customer requirements Vs Developer requirements • Requirements given by customers are mandatory requirements • Must be captured in the product • Requirements that are introduced by developers to support customers expectations are called developer requirements • Support design activities • Preferences • Consequences of other requirements • … Lecture3

23. Developer requirements are different from design issues • Developer requirements must still describe only WHAT of the problem, but not HOW. • Requirements must not dictate HOW to develop the product. • Developer requirements may arise from system constraints, limitations and other conditions that were imposed by the environment. Lecture3

24. Example • Customer requirement: • Data must be stored in files, and no external database will be used. • Developer requirement: • Data must be stored in indexed sequential files because of the success in using this type of files in previous projects Lecture3

25. Functional and non-functional requirements • Functional requirements • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. • Non-functional requirements • constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Lecture3

26. 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 • Functional user requirements may be high-level statements of what the system should do, but also functional system requirements should describe the system services in detail Lecture3

27. Examples of functional requirements • The user shall be able to search either all of the initial set of databases or select a subset from it. • The system shall provide appropriate viewers for the user to read documents in the document store. • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area. Lecture3

28. Requirements imprecision • Problems arise when requirements are not precisely stated • Ambiguous requirements may be interpreted in different ways by developers and users • Consider the term ‘appropriate viewers’ • User intention - special purpose viewer for each different document type • Developer interpretation - Provide a text viewer that shows the contents of the document Lecture3

29. Requirements completeness and consistency • In principle requirements should be both complete and consistent • Complete • They should include descriptions of all facilities required • Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities • In practice, it is very difficult / impossible to produce a complete and consistent requirements document Lecture3

30. Nonfunctional Requirements: Purpose • Define the qualitative aspects of requirements • May restrict the design and implementation • May restrict the process and/or the product • May arise due to • standards • organizational policies • interoperability constraints • … Lecture3

31. Distinction between functional and non-functional requirements • The system shall ensure that data is protected from unauthorized access • Non-functional requirement (Security) • The system shall include a user authorization mechanism through <login, password>; only users with registered login id and valid password can use the system • Functional requirement • not arising from the application domain • May be a developer requirement Lecture3

32. Classifications of non-functional requirements • Some from IEEE Std 830-1993 • Interface requirements (interoperability constraints) • Security requirements (user authorization constraints) • Portability requirements (system usage constraints) • Reliability requirements • Safety requirements • Documentation requirements (Standards constraints) • Acceptance requirements (Standards constraints) Lecture3

33. Non-functional requirements • Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. • Process requirements may also be specified mandating a particular CASE system, programming language or development method • Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless Lecture3

34. Non-functional requirements • Concerned with qualitative aspects of the software product • Reliability • Maintainability • Security • Portability • … • SRS may include a set of non-functional requirements as expected by the customer(s) • May also include developer requirements to support and to justify how to achieve these non-functional requirements Lecture3

35. Non-functional requirements User concerns User needs Functional Ease of use Usability Unauthorized Access Security Chances of Failure Reliability Performance Resource Utilization Efficiency Performance verification Verifiability Ease of Interfacing Interoperability Change Ease of change Maintainability Ease of transport Portability Relationship between user needs and non-functional requirements Lecture3

36. Non-functional Requirements measures Lecture3

37. Non-functional Requirements interaction • Conflicts between different non-functional requirements are common in complex systems • Spacecraft system • To minimise weight, the number of separate chips in the system should be minimised • To minimise power consumption, lower power chips should be used • However, using low power chips may mean that more chips have to be used. Which is the most critical requirement? Lecture3

38. Exercise Classify the following aspects of an airline reservation system into F for “functional”, NF for “non-functional” and X for should not be a requirement. • How information about flights, passengers and booking are entered • What information appears on tickets and reports • How fares are calculated • What information must be stored in the database that travel agents and others access • The system should be designed so it can be extended to handle a frequent flier plan • The system must be available at all times. Only 2 minutes downtime a week is to be permitted • A merge sort algorithm must be used to sort the flights by departure time Lecture3

39. Requirements analysis • A process by which requirements are categorized, organized into groups and explored for relationships with other requirements • Main focus is for consistency, ambiguities and omissions • Preferences and ranking among requirements are identified Lecture3

40. Some guidelines for requirements analysis • Identify and remove inconsistencies • no two requirements contradict with each other • mathematical analysis is ideal, but hard to perform • often done using requirements analysis experts • Identify and remove ambiguities • a requirement is ambiguous if there is more than one interpretation for the same requirement • ambiguities can be removed by checking with the customers Lecture3

41. Some guidelines for requirements analysis (continued) • Check for the relevance of each requirement to the goal or objective of the end product • unnecessary and redundant requirements can be removed • Check whether each requirement is implementable, verifiable or testable • the quality assurance team will generally confirm this check for each requirement Lecture3

42. Ambiguous statement in requirements The new number is first placed in the last position of the array and then compared with the previous number. If it is greater, then the two are interchanged. Corrected: The new number n is first placed in the last position of the array and then compared with the number p in the previous position of the array. If n is greater, then n and p are interchanged. Lecture3

43. Statements in requirements that lead to design errors • Telecommunication system example • One requirement to create a password says • The user can choose any sequence of six keys on the telephone receiver as the password • Another requirement says • Enter the password (must be six characters) and then press the pound (#) key • Not possible to correct the password at this stage because the user has not entered into the system Lecture3

44. Another example • A table with four values in each row • One requirement says • Enter the four values given in the input into a new row. If any of the values is not specified in the input, leave that column in the table empty. • Another requirement says • The value in the first column is the key. If, for a given key a match is found, then the second and fourth values are multiplied and the result is output. • What happens if the value is empty? Lecture3

45. One more example… • A security system • One requirement says • If condition C is violated, an alarm must be raised and the system must be shut down immediately. • Another requirement says • When an alarm is raised, the sensor S must be activated to close the door. • How can S be activated when the system is shut down? Lecture3

46. Exercise Review the following short statement of functional requirements for a restaurant advisor system, point out any problems you find. This system will allow people to choose a restaurant in a city. Users enter one or more of the following criteria, and then the system searches its database for suitable restaurants: food type, price range, neighborhood, size, service type (fast food, cafeteria, buffet, full service), smoking arrangements (none allowed, separately ventilated section, non-separately-ventilated section). The user can also specify a desired day and time-period, and the number of people in their party. The system will tap into the reservation database( of participating restaurants) and only display restaurants that have available space. After entering the criteria, the user clicks on “search”, and the system displays a list of matching restaurants. For restaurants that participate in the automated reservation system, the user can click on “reserve” next to a selection in order to make a reservation. Lecture3

47. Some Techniques for Gathering and Analysing Requirements • Observation • Read documents and discuss requirements with users • Shadowing important potential users as they do their work • ask the user to explain everything he or she is doing • Session videotaping • Interviewing • Conduct a series of interviews • Ask about specific details • Ask about the stakeholder’s vision for the future • Ask if they have alternative ideas • Ask for other sources of information • Ask them to draw diagrams Lecture3

48. Gathering and Analysing Requirements • Brainstorming • Appoint an experienced moderator • Arrange the attendees around a table • Decide on a ‘trigger question’ • Ask each participant to write an answer and pass the paper to its neighbour • Joint Application Development (JAD) is a technique based on intensive brainstorming sessions Lecture3

49. Gathering and Analysing Requirements • Prototyping • The simplest kind: paper prototype • a set of pictures of the system that are shown to users in sequence to explain what would happen • The most common: a mock-up of the system’s UI • Written in a rapid prototyping language • Does not normally perform any computations, access any databases or interact with any other systems • May prototype a particular aspect of the system Lecture3

50. Gathering and Analysing Requirements • Use case analysis • Determine the classes of users that will use the facilities of this system (actors) • Determine the tasks that each actor will need to do with the system Lecture3