Software Requirement Analysis and Problem Definition Process
Understanding software requirements is crucial for effective design. Domain analysis helps in grasping the application domain, while defining the problem scope sharpens the focus. For instance, in the context of an airline reservation system, gathering information on user needs, business rules and constraints, system capabilities, and integration requirements is vital. By narrowing down and specifying the problems and goals, developers can streamline the development process and deliver efficient solutions.
Uploaded on Sep 14, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
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.
Example Outline in one paragraph the information you would need to gather in order to perform domain analysis for the airline reservation system. 9/14/2024 Lecture3 2
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 9/14/2024 Lecture3 3
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 9/14/2024 Lecture3 4
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 9/14/2024 Lecture3 5
Example A university registration system Initial list of problems with very broad scope Narrowed scope Scope of another system browsing courses browsing courses room allocation room allocation registering registering exam scheduling exam scheduling fee payment fee payment 9/14/2024 Lecture3 6
Example Define the problem and scope for a system that handles university degree requirements and registrations 1. 2. 3. 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 4. 5. 6. 7. 8. 9. 10. 11. 9/14/2024 Lecture3 7
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? 9/14/2024 Lecture3 8
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? 9/14/2024 Lecture3 9
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 9/14/2024 Lecture3 10
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 9/14/2024 Lecture3 11
Requirements Document Each functional requirement is given in the following format: Index: Name: Purpose: Input parameters: Action: Output parameters: Exceptions: Remarks: Cross-references: 9/14/2024 Lecture3 12
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 9/14/2024 Lecture3 13
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 9/14/2024 Lecture3 14
RE process - inputs and outputs Existing systems information Agreed requirements Stakeholder needs Requirements engineering process System specification Organisational standards System models Regulations Domain information 9/14/2024 Lecture3 15
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.) 9/14/2024 Lecture3 16
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 9/14/2024 Lecture3 17
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 9/14/2024 Lecture3 18
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 9/14/2024 Lecture3 19
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 9/14/2024 Lecture3 20
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. 9/14/2024 Lecture3 21
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 9/14/2024 Lecture3 22
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. 9/14/2024 Lecture3 23
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 9/14/2024 Lecture3 24
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. 9/14/2024 Lecture3 25
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 9/14/2024 Lecture3 26
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. 9/14/2024 Lecture3 27
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 9/14/2024 Lecture3 28
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 9/14/2024 Lecture3 29
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 9/14/2024 Lecture3 30
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 9/14/2024 Lecture3 31
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) 9/14/2024 Lecture3 32
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 9/14/2024 Lecture3 33
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 9/14/2024 Lecture3 34
Relationship between user needs and non-functional requirements Non-functional requirements User concerns User needs Functional Ease of use Unauthorized Access Chances of Failure Resource Utilization Performance verification Ease of Interfacing Usability Security Reliability Performance Efficiency Verifiability Interoperability Change Ease of change Maintainability Ease of transport Portability 9/14/2024 Lecture3 35
Non-functional Requirements measures Property Speed Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems Size Ease of use Reliability Robustness Portability 9/14/2024 Lecture3 36
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? 9/14/2024 Lecture3 37
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. 1. 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 2. 3. 4. 5. 6. 7. 9/14/2024 Lecture3 38
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 9/14/2024 Lecture3 39
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 9/14/2024 Lecture3 40
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 9/14/2024 Lecture3 41
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. 9/14/2024 Lecture3 42
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 9/14/2024 Lecture3 43
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? 9/14/2024 Lecture3 44
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? 9/14/2024 Lecture3 45
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. 9/14/2024 Lecture3 46
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 9/14/2024 Lecture3 47
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 9/14/2024 Lecture3 48
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 9/14/2024 Lecture3 49
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 9/14/2024 Lecture3 50
