2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
0 likes286 views
Module 2 covers software requirements focusing on functional and non-functional requirements, user requirements, the software requirements document, and the requirements engineering process. It discusses techniques for requirement elicitation, validation, and various system models such as context, behavioral, data, and object models. The importance of clearly defined requirements in software development is emphasized, outlining how these requirements impact the overall project and product success.
![Non-functional Requirements
• A classification of non-functional requirements [Fig. 6.3, SE-7]:
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements](https://image.slidesharecdn.com/2ndmodulesoftwarerequirementsswengg22cse141-230908090202-bb35799b/85/2nd-MODULE-Software-Requirements-_-SW-ENGG-22CSE141-pdf-13-320.jpg)
![Scenario-Based Models
31
“[Use-cases] a“[Use-cases] are simply an aid to
defining what exists outside the system (actors) and
what should be performed by the system (use-cases).”
- Ivar Jacobson
Represented via use cases
1 Creating Preliminary use case
What to write about? – Inception and elicitation will
provide the information for begin with use cases.
2 Refining Preliminary use case
3 Writing a formal use case](https://image.slidesharecdn.com/2ndmodulesoftwarerequirementsswengg22cse141-230908090202-bb35799b/85/2nd-MODULE-Software-Requirements-_-SW-ENGG-22CSE141-pdf-31-320.jpg)
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
- 2. 2
- 3. SOFTWARE ENGINEERING Course Code: 22CSE141 Module 2: Software Requirements Functional and nonfunctional requirements, User requirements – Software requirements Document – Requirement Engineering Process – Feasibility studies, Requirements elicitation and analysis, Requirements validation – System models: Context Models, Behavioral models, Data models, Object models, structured methods.
- 4. 4
- 5. Requirements • Requirements = services the system is expected to provide + constraints placed on the system. • Requirements engineering = gathering, negotiating, analyzing, and documenting requirements. • The requirements could be expressed at various levels of abstraction. • The way requirements are defined has a major impact on the development of the software product.
- 6. REQUIREMENTS ENGINEERING •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.
- 7. REQUIREMENT ENGG. • It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification • 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. 7
- 8. 8
- 9. 9
- 10. Contents • Requirements • Functional • Non-Functional • User Requirements • The Software Requirements Document 10 / 26
- 11. Functional and Non functional Requirements Functional Requirements: • These are the requirements that the end user specifically demands as basic facilities that the system should offer. • All these functionalities need to be necessarily incorporated into the system as a part of the contract. • describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations Non Functional Requirements • These are basically the quality constraints that the system must satisfy according to the project contract. • The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. • represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process. 11
- 12. FUNCTIONAL REQUIREMENTS NON FUNCTIONAL REQUIREMENTS 1. A functional requirement defines a system or its component. A non-functional requirement defines the quality attribute of a software system. 2. It specifies “What should the software system do?” It places constraints on “How should the software system fulfill the functional requirements?” 3. Functional requirement is specified by User. Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers. 4. It is mandatory. It is not mandatory. 5. It is captured in use case. It is captured as a quality attribute. 6. Defined at a component level. Applied to a system as a whole. 7. Helps you verify the functionality of the software. Helps you to verify the performance of the software. 8. Functional Testing like System, Integration, End to End, API testing, etc are done. Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done. 9. Usually easy to define. Usually more difficult to define. 12
- 13. Non-functional Requirements • A classification of non-functional requirements [Fig. 6.3, SE-7]: Performance requirements Space requirements Usability requirements Efficiency requirements Reliability requirements Portability requirements Interoperability requirements Ethical requirements Legislative requirements Implementation requirements Standards requirements Delivery requirements Safety requirements Privacy requirements Product requirements Organizational requirements External requirements Non-functional requirements
- 14. Non-functional Requirements.. • Metrics that can be used to quantitatively specify and verify non- functional requirements. Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Jain University 14 / 26
- 15. User Requirements •User requirements: • Should be understood by the user, and should not address design and implementation aspects • Should focus on the key facilities required •Problems with requirements written in natural language: • Lack of clarity, ambiguity, various interpretations possible • Confusion, lack of separation between different types of requirements • Mixture of several requirements in the same statement • Hard to modularize and thus hard to find connections between requirements Jain University 15 / 26
- 16. User Requirements … • Guidelines for writing requirements: • Create and use a standard format for the entire software requirements specification • Highlight important parts of the requirement statements • Use consistently the language (difference between “should” and “shall”) • Avoid computer jargon Jain University 16 / 26
- 17. The Software Requirements Document • This document, also called Software Requirements Specification (SRS), is the official description of the system’s requirements (includes user and system reqs.) • Heninger (1980) recommends that an SRS should: • Specify only external system behaviour • Specify constraints on implementation • Be easy to change • Serve as a reference for maintainers • Record forethought about the software life cycle • Describe acceptable responses to undesired events Jain University 17 / 26
- 18. Software Requirements Document • SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard): • Introduction • General description • Specific requirements • Appendices • Index • This structure needs to be tailored for each particular organization 18 / 26
- 19. Software Requirements Specification • A software requirements specification (SRS) is a document that is created when a detailed description of all aspects of the software to be built must be specified before the project is to commence. • It is important to note that a formal SRS is not always written 1. Introduction • 1.1 Purpose • 1.2 Document Conventions • 1.3 Intended Audience and Reading Suggestions • 1.4 Project Scope • 1.5 References 2. Overall Description • 2.1 Product Perspective • 2.2 Product Features • 2.3 User Classes and Characteristics • 2.4 Operating Environment 19
- 20. • 2.5 Design and Implementation Constraints • 2.6 User Documentation • 2.7 Assumptions and Dependencies 3. System Features • 3.1 System Feature 1 • 3.2 System Feature 2 (and so on) 4. External Interface Requirements • 4.1 User Interfaces • 4.2 Hardware Interfaces • 4.3 Software Interfaces • 4.4 Communications Interfaces 5. Other Nonfunctional Requirements • 5.1 Performance Requirements • 5.2 Safety Requirements • 5.3 Security Requirements • 5.4 Software Quality Attributes 6. Other Requirements 20
- 22. Validating Requirements 22 Is each requirement consistent with the overall objective for the system/product? Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements?
- 23. Validating Requirements 23 Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?
- 24. Eliciting Requirements 24 1 Collaborative Requirements Gathering meetings are conducted and attended by both software engineers and customers rules for preparation and participation are established an agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used the goal is to identify the problem propose elements of the solution negotiate different approaches, and specify a preliminary set of solution requirements
- 25. 2. Quality Function Deployment Normal requirements: Requirements which are stated during the meeting with the customer Example:) normal requirements might be requested types of graphical displays, specific system functions Expected requirements: Requirements are implicit to the product or system that are not explicitly stated by the customer. Exciting requirements: features go beyond the customer’s expectations and prove to be very satisfying when present. Example:) software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product. 25
- 26. 3. Usage Scenarios • A usage scenario, or scenario for short, describes a real- world example of how one or more people or organizations interact with a system. • They describe the steps, events, and/or actions which occur during the interaction. • Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they're performed. 26
- 27. 3. Usage Scenarios •Usage scenarios are applied in several development processes, often in different ways. •In derivatives of the Unified Process (UP) they are used the help move from use cases to sequence diagrams. •The basic strategy is to identify a path though a use case, or through a portion of a use case, and then write the scenario as an instance of that path. 27
- 28. 3. Usage Scenarios … • For example, the text of the "Withdraw Funds" use case would indicate what should happens when everything goes right, in this case the funds exist in the account and the ATM has the funds. • This would be referred to as the "happy path" or basic course of action. • The use case would include alternate paths describing what happens when mistakes occur, such as there being insufficient funds in the account or the ATM being short of cash to disburse to customers. • You would write usage scenarios that would explore the happy path, such as the first scenario above, as well as each of the alternate courses. You would then develop a sequence diagram exploring the implementation logic for each scenario. 28
- 29. What is Requirement Analysis? 29 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.
- 30. Elements of Requirement Analysis 30
- 31. Scenario-Based Models 31 “[Use-cases] a“[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).” - Ivar Jacobson Represented via use cases 1 Creating Preliminary use case What to write about? – Inception and elicitation will provide the information for begin with use cases. 2 Refining Preliminary use case 3 Writing a formal use case
- 32. Scenario-Based Models 32 Use Case Diagram of Safe Home System
- 33. Class-Based Modeling 33 Class-based Modeling includes: 1. Identifying classes (often from use cases as a starting point) 2. Identifying associations between classes 3. Identifying general attributes and responsibilities of classes 4. Modeling interactions between classes 5. Modeling how individual objects change state -- helps identify operations 6. Checking the model against requirements, making adjustments, iterating through the process more than once.
- 34. 34
- 35. Context Model – Microwave oven model 35 Full power Enabled do: operate oven Full power Half power Half power Full power Number Timer Door open Door closed Door closed Door open Start do: set power = 600 Half power do: set power = 300 Set time do: get number exit: set time Disabled Operation Timer Cancel Waiting do: display time Waiting do: display time do: display 'Ready' do: display 'Waiting'
- 36. Microwave oven state description 36 State Description Waiting The oven is waiting for input. The display shows the current time. Half power The oven power is set to 300 watts. The display shows ‘Half power’. Full power The oven power is set to 600 watts. The display shows ‘Full power’. Set time The cooking time is set to the user’s input value. The display shows the cooking time selected and is updated as the time is set. Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’. Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’. Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding.
- 37. Microwave oven stimulus 37 Stimulus Description Half power The user has pressed the half power button Full power The user has pressed the full power button Timer The user has pressed one of the timer buttons Number The user has pressed a numeric key Door open The oven door switch is not closed Door closed The oven door switch is closed Start The user has pressed the start button Cancel The user has pressed the cancel button
- 38. Behavioural Model – State Diagram 38
- 39. 39 Data models
- 40. Data Flow Models • Data flow diagrams are used to model the system’s data processing • These show the processing steps as data flows through a system • Intrinsic part of many analysis methods • Simple and intuitive notation that customers can understand • Show end-to-end processing of data. 40
- 41. Data Flow Diagrams (DFD) •DFDs model the system from a functional perspective. •Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system •Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment 41
- 42. Elements of a DFD •Processes • Change the data. Each process has one or more inputs and outputs •Data stores used by processes to store and retrieve data (files, DBs) •Data flows -movement of data among processes and data stores •External entities - outside things which are sources or destinations of data to the system 42
- 43. DFD for Order Processing 43 Complete order form Order details + blank order form Validate order Record order Sendto supplier Adjust available budget Budget file Orders file Completed order form Signed order form Signed order form Checked and signed order + order notification Order amount + account details Signed order form Order details
- 44. What is Object Oriented Data Modeling? •Centers around objects and classes •Involves inheritance •Encapsulates both data and behavior •Benefits of Object-Oriented Modeling • Ability to tackle challenging problems • Improved communication between users, analysts, designer, and programmers • Increased consistency in analysis and design • Explicit representation of commonality among system components • System robustness • Reusability of analysis, design, and programming results 44
- 45. OO vs EER Data Modeling Object Oriented 45 ER Class Entity type Object Entity Instance Association Relationship Inheritance of attributes Inheritance of attributes Inheritance of behavior No representation of behavior Object-oriented modeling is frequently accomplished using the Unified Modeling Language (UML)
- 46. Classes and Objects •Class: An entity that has a well-defined role in the application domain, as well as state, behavior, and identity • Tangible: person, place or thing • Concept or Event: department, performance, marriage, registration • Artifact of the Design Process: user interface, controller, scheduler •Object: a particular instance of a class 46 Objects exhibit BEHAVIOR as well as attributes Different from entities
- 47. State, Behavior, Identity •State: attribute types and values •Behavior: how an object acts and reacts •Behavior is expressed through operations that can be performed on it •Identity: every object has a unique identity, even if all of its attribute values are the same 47
- 48. 48 Class diagram shows the static structure of an object-oriented model: object classes, internal structure, relationships. UML class and object diagram Class diagram showing two classes
- 49. 49 Object diagram shows instances that are compatible with a given class diagram. UML class and object diagram … Object diagram with two instances
- 50. 50 Object diagram for customer order
- 51. STRUCTURED ANALYSIS • It considers data and the processes that transform the data as separate entities. • Data objects are modeled in a way that defines their attributes and relationships. • Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system. 51
- 52. STRUCTURED ANALYSIS 1. Source traceability information links the requirements to the stakeholders who proposed the requirements and to the rationale for these requirements. When a change is proposed, you use this information to find and consult the stakeholders about the change. 2. Requirements traceability information links dependent requirements within the requirements document. You use this information to assess how many requirements are likely to be affected by a proposed change and the extent of consequential requirements changes that may be necessary. 3. Design traceability information links the requirements to the design modules where these requirements are implemented. You use this information to assess the impact of proposed requirements changes on the system design and implementation. 52
- 53. 53 SUMMARY Module 2: Software Requirements In Module 2 we discussed the following topics, Functional and nonfunctional requirements, User requirements, Software requirements Document Requirement Engineering Process Feasibility studies, Requirements elicitation and analysis, Requirements validation System models: Context Models, Behavioral models, Data models, Object models, tructured methods.