Software Engineering Unit 4- Requirement Analysis and Specification

Transcription

1 Software Engineering Unit 4- Requirement Analysis and Specification Requirement Engineering The process to gather the software requirements from client, analyze and document them is known as requirement engineering. The goal of requirement engineering is to develop and maintain sophisticated and descriptive System Requirements Specification document. Software Requirements The term user requirements means the high-level abstract requirements and system requirements means the detailed description of what the system should do. User requirements and system requirements may be defined as follows: 1. User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate. 2. System requirements are structural language, i.e more detailed descriptions of the software system s functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers. Example: Patient Management System User Requirement: 1. The PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month. System Requirements: 1.1 On the last working day of each month, a summary of the drugs prescribed, their cost, and the prescribing clinics shall be generated. 1.2 The system shall automatically generate the report for printing after on the last working day of the month. Prof Rina Raval 1

2 1.3 A report shall be created for each clinic and shall list the individual drug names, the total number of prescriptions, the number of doses prescribed, and the total cost of the prescribed drugs. 1.4 If drugs are available in different dose units (e.g., 10 mg, 20 mg) separate reports shall be created for each dose unit. 1.5 Access to all cost reports shall be restricted to authorized users listed on a management access control list. Attendance Management System User Requirement: 1. System should generate report of attendance of every student at the end of month. System Requirements: 1.1 On the last working day of each month a detail regarding student name, branch, semester, college shift(if applicable),total attendance shall be generated. 1.2 The system shall automatically generate the report for printing after on the last working day of the month. 1.3 If student is present in one lecture(one subject) and absent in another(another subject), than report for the same should be generated. 1.4 Whether student is attending labs and lectures both or either of them, that report should be created. 1.5 Whether student is attending regular or proxy lecture, that report should be created. 1.6 If one branch have multiple divisions,then in which division student is belonging, that report should be generated. 1.7 Access to all reports shall be restricted to authorized users listed by organization. Software system requirements are often classified as functional requirements or nonfunctional requirements: Functional Requirements Functional requirements These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do. Requirements, which are related to functional aspect of software fall into this category. They define functions and functionality within and from the software system. For example Prof Rina Raval 2

3 Functional requirement of a cup is to hold tea of coffee. Functional requirement of an is to send when condition is met. Typical functional requirements include: Business Rules Transaction corrections, adjustments and cancellations Administrative functions Authentication Authorization levels Audit Tracking External Interfaces Certification Requirements Reporting Requirements Historical Data Legal or Regulatory Requirements EXAMPLES - Search option given to user to search from various invoices. User should be able to mail any report to management. Users can be divided into groups and groups can be given separate rights. Should comply business rules and administrative functions. Software is developed keeping downward compatibility intact. Non-Functional Requirements Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole, rather than individual system features or services. Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of. Non-functional requirement of a cup is to hold tea/coffee at some degree of temperature. Non-functional requirement of an is to send in between 12 hours. 1.Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. 2. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define new system services that are required. In addition, it may also generate requirements that restrict existing requirements. Following are the nonfunctional requirement types: Prof Rina Raval 3

4 1. Product requirements These requirements specify or constrain the behavior of the software. Examples include performance requirements on how fast the system must execute and how much memory it requires, reliability requirements that set out the acceptable failure rate, security requirements, and usability requirements. 2. Organizational requirements These requirements are broad system requirements derived from policies and procedures in the customer s and developer s organization. Examples include operational process requirements that define how the system will be used, development process requirements that specify the programming language, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system. 3. External requirements This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that the system will be acceptable to its users and the general public. For PMS system given above, functional requirements will be, 1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Prof Rina Raval 4

5 3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee number. For PMS system given above, non-functional requirements will be, PRODUCT REQUIREMENT The PMS shall be available to all clinics during normal working hours (Mon Fri, ). Downtime within normal working hours shall not exceed five seconds in any one day. ORGANIZATIONAL REQUIREMENT Users of the PMS system shall authenticate themselves using their health authority identity card. EXTERNAL REQUIREMENT The system shall implement patient privacy provisions. Non-functional requirements include Performance for example: response time, throughput, utilization, static volumetric Scalability Capacity Availability Reliability Recoverability Maintainability Serviceability Security Regulatory Manageability Environmental Data Integrity Usability Interoperability Logging Storage Configuration Cost Flexibility Disaster recovery Accessibility Prof Rina Raval 5

6 Requirement Engineering Process It is a four step process, which includes Feasibility Study Requirement Gathering Software Requirement Specification Software Requirement Validation Let us see the process briefly - Feasibility study When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop. This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability. The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken. Requirement Gathering If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include. Software Requirement Specification SRS is a document created by system analyst after the requirements are collected from various stakeholders. SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc. The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team. Prof Rina Raval 6

7 SRS should come up with following features: User Requirements are expressed in natural language. Technical requirements are expressed in structured language, which is used inside the organization. Design description should be written in Pseudo code. Format of Forms and GUI screen prints. Conditional and mathematical notations for DFDs etc. Software Requirement Validation After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions - If they can be practically implemented If they are valid and as per functionality and domain of software If there are any ambiguities If they are complete If they can be demonstrated Requirement Elicitation Process Requirement elicitation process can be depicted using the folloiwng diagram: Requirements gathering - The developers discuss with the client and end users and know their expectations from the software. Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience. Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised. Prof Rina Raval 7

8 The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing Requirement Engineering Tasks It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation, specification, validation, and management. It is important to note that some of these tasks occur in parallel and all are adapted to the needs of the project. Inception At project inception, you establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the other stakeholders and the software team. Elicitation. It certainly seems simple enough ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. But it isn t simple it s very hard. Number of problems that are encountered as elicitation occurs are as follow: Problems of scope. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be obvious, specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable. Prof Rina Raval 8

9 Problems of volatility. The requirements change over time. Elaboration. The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. This task focuses on developing a refined requirements model that identifies various aspects of software function, behavior, and information. Elaboration is driven by the creation and refinement of user scenarios that describe how the end user (and other actors) will interact with the system. Each user scenario is parsed to extract analysis classes business domain entities that are visible to the end user. Negotiation. It isn t unusual for customers and users to ask for more than can be achieved, given limited business resources. It s also relatively common for different customers or users to propose conflicting requirements, arguing that their version is essential for our special needs. You have to reconcile these conflicts through a process of negotiation. Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority. Using an iterative approach that prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction. Specification. In the context of computer-based systems (and software), the term specification means different things to different people. A specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these. Validation. The work products produced as a consequence of requirements engineering are assessed for quality during a validation step. Requirements validation examines the specification5 to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product Prof Rina Raval 9

10 Requirements management. Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. Requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds Requirement Elicitation Techniques / Methods to collect requirements: Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development. There are various ways to discover requirements: Interviews Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as: Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly. Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased. Oral interviews Written interviews One-to-one interviews which are held between two persons across the table. Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved. Surveys Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system. Prof Rina Raval 10

11 Questionnaires A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled. A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended. Task analysis Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected. Domain Analysis Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements. Brainstorming An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis. Prototyping Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client s end for developer s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering. Observation Team of experts visit the client s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software. Prof Rina Raval 11

12 Software Requirements Characteristics Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined. A complete Software Requirement Specifications must be: Clear Correct Consistent Coherent Comprehensible Modifiable Verifiable Prioritized Unambiguous Traceable Credible source Requirement Analysis: Requirements analysis specifies software s operational characteristics, indicates software's interface with other system elements, establishes constraints that software must meet. Requirements analysis allows the software engineer (called an analyst or modeler in this role) to: elaborate on basic requirements established during earlier requirement engineering tasks build models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed. It is a bridge between system description and design model. Prof Rina Raval 12

13 Analysis Rules of Thumb The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other nonfunctional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be. Domain Analysis In this one has to Define the domain to be investigated. Collect a representative sample of applications in the domain. Analyze each application in the sample. Develop an analysis model for the objects. The requirements modeling action results in one or more of the following types of models: Scenario-based models of requirements from the point of view of various system actors Data models that depict the information domain for the problem Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements Prof Rina Raval 13

14 Flow-oriented models that represent the functional elements of the system and how they transform data as it moves through the system Behavioral models that depict how the software behaves as a consequence of external events 1. Scenario-Based Modeling Use-cases are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (1) What should we write about? (2) How much should we write about it? (3) How detailed should we make our description? (4) How should we organize the description? What to Write About? Inception and elicitation provide you with the information you ll need to begin writing use cases. Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to identify stakeholders define the scope of the problem specify overall operational goals establish priorities outline all known functional requirements, and describe the things (objects) that will be manipulated by the system. To begin developing a set of use cases, list the functions or activities performed by a specific actor. How Much to Write About? As further conversations with the stakeholders progress, the requirements gathering team develops use cases for each of the functions noted. In general, use cases are written first in an informal narrative fashion. If more formality is required, the same use case is rewritten using a structured format similar to the one proposed. Use-Cases are scenarios that describes a thread of usage for a system actors represent roles people or devices play as the system functions users can play a number of different roles for a given scenario Developing a Use-Case will be considering following: What are the main tasks or functions that are performed by the actor? What system information will the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? Prof Rina Raval 14

15 2.Data Modeling Use case diagram for safe home system: If software requirements include the need to create, extend, or interface with a database or if complex data structures must be constructed and manipulated, the software team may choose to create a data model as part of overall requirements modeling. A software engineer or analyst defines all data objects that are processed within the system, the relationships between the data objects, and other information that is pertinent to the relationships. The entity-relationship diagram (ERD) addresses these issues and represents all data objects that are entered, stored, transformed, and produced within an application. A data object is a representation of composite information that must be understood by software. A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file). For example, a person or a car can be viewed as a data object in the sense that either can be defined in terms of a set of attributes. The description of the data object incorporates the data object and all of its attributes Data attributes define the properties of a data object and take on one of three different characteristics. They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make reference to another instance in another table. In addition, one or more of the attributes must be defined as an identifier that is, the identifier attribute becomes a key when we want to find an Prof Rina Raval 15

16 instance of the data object. In some cases, values for the identifier(s) are unique, although this is not a requirement. Referring to the data object car, a reasonable identifier might be the ID number Data objects are connected to one another in different ways. Consider the two data objects, person and car. These objects can be represented using the simple notation illustrated in the figure below. A connection is established between person and car because the two objects are related. But what are the relationships? To determine the answer, you should understand the role of people (owners, in this case) and cars within the context of the software to be built. You can establish a set of object/ relationship pairs that define the relevant relationships. For example A person owns a car. A person is insured to drive a car 3. Class based modeling: Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. The elements of a class-based model include classes and objects, attributes, operations, class responsibility-collaborator (CRC) models, collaboration diagrams, and packages Identifying Analysis Classes Analysis classes manifest themselves in one of the following ways: External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. Prof Rina Raval 16

17 Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. Organizational units (e.g., division, group, team) that are relevant to an application. Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects Potential class for inclusion in the analysis model: Retained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function. Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way. Multiple attributes. During requirement analysis, the focus should be on "major" information; a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity. Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class. Common operations. A set of operations can be defined for the potential class and these operations apply to all instances of the class. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model. Defining Attributes Attributes describe a class that has been selected for inclusion in the analysis model. Build two different classes for professional baseball players For Playing Statistics software: name, position, batting average, fielding percentage, years played, and games played might be relevant Prof Rina Raval 17

18 For Pension Fund software: average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like. Defining Operations Do a grammatical parse of a processing narrative and look at the verbs.operations can be divided into four broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting) (2) operations that perform a computation (3) operations that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of a controlling event. Class Diagram for the System Class Responsibilities System intelligence should be distributed across classes to best address the needs of the problem. Each responsibility should be stated as generally as possible.information and the behavior related to it should reside within the same class. Information about one thing should be localized with a single class, not distributed across multiple classes. Collaborations Classes fulfill their responsibilities in one of two ways: A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes. Collaborations identify relationships between classes. Prof Rina Raval 18

19 Associations and Dependencies Two analysis classes are often related to one another in some fashion In UML these relationships are called associations can be refined by indicating multiplicity. In such cases, a client-class depends on the server class in some way and a dependency relationship is established. 4. Flow oriented modeling This consists of DFDs. Example: Booking room in hotel 5.Behavior modeling This consists of State diagrams which has states and transitions from those states to other states. Example: Operating system process states Prof Rina Raval 19

20 Software Requirement Specification A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform. It is usually signed off at the end of requirements engineering phase. Characteristics of good SRS 1. Unambiguous 2. Complete 3. Verifiable 4. Consistent 5. Modifiable 6. Traceable 7. Usable during the Operation and Maintenance Phase Desired SRS Characteristics Complete Consistent Changeable Traceable Desired Prof Rina Raval 20

21 Generally contents of SRS will be as follow. According to the product some content may be added or removed. SRS Table of Contents 1. Introduction 1. Purpose 2. Scope 3. Definitions 4. References 5. Overview 2. General Description 1. Product Perspective 2. Product Functions 3. User Characteristics 4. General Constraints 5. Assumptions and Dependencies 3. Specific Requirements 3.1 Functional Requirements Func Req Introduction Inputs Processing Outputs Func Req External Interface Requirements User Interface Hardware Interfaces Software Interfaces Communication Interfaces Prof Rina Raval 21

22 3.3 Performance Requirements 3.4 Design Constraints Standards Compliance Hardware Limitations 3.5 Attributes Security Maintainability 3.6 Other Requirements Database Prof Rina Raval 22