quiz2.pdf

Software Engineering Fundamentals Week 2 – Part A: Requirements Engineering The Importance of Requirements Engineering You need to know what you need to program before you can program it. What a proposed system is to do, not how it is supposed to do it....

Software Engineering Fundamentals Week 2 – Part A: Requirements Engineering The Importance of Requirements Engineering You need to know what you need to program before you can program it. What a proposed system is to do, not how it is supposed to do it. The Importance of Requirements Engineering 1. Foundation of Successful Software Development Requirements engineering is the process of understanding, analysing, documenting, and managing software requirements. It serves as the foundation upon which the entire development process is built. If you get the foundation wrong …. 2. Delivering a High-Quality Software Product Well-defined and well-understood requirements are crucial for delivering a high-quality software product that meets the needs and expectations of stakeholders. 3. Consequences of Poor Requirements Engineering can include: cost overruns project delays dissatisfied users (not meeting their needs) Different Types of Requirements 1. Functional Requirements Functional requirements identify specific tasks and functions that the software must perform to meet user needs and achieve its intended purpose. 2. Non-Functional Requirements Non-functional requirements define the quality attributes and characteristics of the software, such as performance, reliability, security, and maintainability. 3. User Requirements User requirements represent the needs and expectations of end-users and stakeholders in terms of usability and user experience. Techniques for Eliciting Requirements from Stakeholders Requirements elicitation: process of gathering and understanding the needs and expectations of stakeholders. Some techniques for effective requirements elicitation include: 1. Interviews Interviews involve direct one-on-one interactions with stakeholders, such as users and clients. Understand their needs, preferences, and pain points. 2. Questionnaires and Surveys Questionnaires and surveys are useful for collecting information from many stakeholders simultaneously. Enables structured data collection and provide insights into common trends and patterns. Techniques for Eliciting Requirements from Stakeholders 3. Observations Observational techniques involve studying users in their ‘natural environments’. Understand their workflow, challenges, and pain points. 4. Focus Groups and Brainstorming Sessions Focus groups and brainstorming sessions promote collaborative discussions and generate innovative ideas. They allow gathering diverse perspectives from multiple stakeholders. Systems cannot be adequately described from a single point of view; many perspectives must be considered. However, total completeness is also a myth. Techniques for Analysing and Specifying Requirements After requirements are gathered, analyse and document them accurately. 1. Scenarios and User Stories Scenarios are specific instances or examples that illustrate how a system or a feature would be used in a particular context. User Stories are short, simple, and non-technical descriptions of a feature or functionality that provides value to the users. Techniques for Analysing and Specifying Requirements: Scenarios Scenarios are specific instances or examples that illustrate how a system or a feature would be used in a particular context. They are often written as narrative descriptions of interactions between users and the system to demonstrate the intended behaviour in various situations. Scenarios can help stakeholders and development teams better understand the practical usage of the system and validate its requirements. Example Scenario 1: Jennifer wants to buy a box of shampoo, five hairbrushes, and 1000 hair pins for her hairdressing salon. Jennifer places an order with the warehouse company to hopefully receive her products the next day. Example Scenario 2: Harry needs a 20kg bag of dry dog food and a feed bowl for his new dog. Harry uses the web interface for the warehouse company to place his order. Unfortunately, the warehouse doesn’t have the brand of dog food that he wants so the warehouse has to place the dog food on back- order. Techniques for Analysing and Specifying Requirements: User Stories User Stories are short, simple, and non-technical descriptions of a feature or functionality that provides value to the users. User stories typically follow a specific format: "As a [type of user], I want [an action] so that [benefit or value].” From Example Scenario 1 and Scenario 2 we can derive the User Story: As a client, I want to place an order with the warehouse, so that I can receive the products I need. Techniques for Analysing and Specifying Requirements After requirements are gathered, analyse and document them accurately. 2. Use Case Diagrams and Use Cases Use case diagrams help visualise the interactions between users and the software system. Use Case Model Use Cases describe the interactions between actors (users or external systems) and the system being developed ¡ Use Case models show both the events the system or business perform, as well as the roles, systems, and devices (actors) that participate in those events. ¡ Use Case models document the functional requirements of a proposed system. Techniques for Analysing and Specifying Requirements: Use Case Diagrams Use case diagrams help visualise the interactions between users and the software system. Giving a high-level overview of the system. Association Typically, the primary actor is trying to achieve a goal by using the system. Enables a quick check for: Actor Completeness Scope System Boundary Use Case Use Case Diagrams: icons Actors: Stick figure: entities that interact / interface with the system. Actors can be people or other systems. Consider the roles the actors play – people can have many different roles Actor Actor Use Case Diagrams: icons Use Case: Oval: represents what the actors want your system to do for them. A use case must be a complete flow of activity, from the actor's point of view, that provides value to the actor. Use Case diagrams normally consist of multiple Use Cases (not just one as in this simplified example diagram). Use Case Use Case Diagrams: icons Association: Line: a general relationship between two nodes in a diagram. Used to indicate an Actor that participates in the performance of the use Association case. Association Use Case Diagrams: icons System Boundary: Rectangle: encasing the Use Cases for the system being analysed. Shows that Actors are outside of the system. Helps define scope of system. System Boundary Use Case Diagrams: Diagramming Tips ¡ Use consistent layout ¡ When feasible, place: Initiating ¡ Use Case icons in the middle Actor ¡ initiating Actors on the left ¡ secondary Actors on the right Secondary Actor Use Case Diagrams: Diagramming Tips ¡ Use consistent layout ¡ When feasible, place: ¡ Use Case icons in an order that mimics time or lifecycle progressing as you move down the page – this is helpful to the reader. ¡ however, time sequence should not always be inferred from the sequence of the Use Cases ¡ Use Case icons that are used less frequently lower in the diagram Use Case Diagrams: Diagramming Tips ¡ Arrowheads on associations between Actor icon and Use Case icon: Initiating ¡ Usage varies amongst organisations Actor ¡ three common conventions: ¡ use arrowhead only to point from initiating Actor to Use Case icon (otherwise, don’t use an arrowhead) – our convention in SEF ¡ never use arrowheads Secondary Actor ¡ use arrowheads only when the communication is one-way (the assumption is that most communication is two-way) Use Case Diagrams: icons Extend: a relationship between two Use Cases: an optional use case (the ‘extending’ use case) and another user case. The ‘extending’ use case provides optional functionality to the other (the ‘extended’ use case). - open arrowhead points from the ‘extending’ Use Case to the ‘extended’ Use Case icon. - the ‘extending’ Use Case is not always necessary to complete the ‘extended’ Use Case. Use Case Diagrams: icons Include: a relationship between two use cases: the ‘included’ use case is logically part of another use case. The ‘included’ use case provides functionality to the other (the ‘including’ use case) that must be completed. The ‘included’ Use Case is always necessary to complete the ‘including’ Use Case. It is not meant to be a Use Case in its own right. Use it when series of steps that achieve a goal are used in multiple Use Cases. Use Case Diagrams: icons Generalisation: a relationship between two Use Cases or two Actors, indicating that one is a specialisation of the other. - closed arrowhead points to the ‘general’ Use Case / Actor - closed arrowhead points away from the ‘specialisation’ Use Case / Actor - the specialised actor can perform all tasks that the general actor can but NOT vice versa ‘general’ = ‘base’ Use Case Diagrams: Diagramming Tips ¡ Generalisations: ¡ place general Use Case icon above specialisation Use Case icon ¡ place general Actor icon above specialisation Actor icon ¡ Includes: ¡ place the ‘included’ Use Case icon either below or next to the ‘including’ Use Case icon – not above Techniques for Analysing and Specifying Requirements: Use Cases Use Cases describe the interactions between actors (users or external systems) and the system being developed. Use Case: Receive and Process Order from Client Actors: Warehouse Clerk, Client Description: This use case describes the process of receiving an order from a client, creating an invoice, packing, and shipping the goods to the client. Steps: 1. Client submits an order with the Warehouse. 2. Warehouse clerk receives the order from the client. 3. Warehouse clerk checks the availability of the products in the order. 4. If products are available, the warehouse clerk creates an invoice. 5. The invoice is sent to the shop floor for packing and shipping. 6. Unfilled items in the order are placed in a waiting list queue (backorder). 7. End. Techniques for Analysing and Specifying Requirements: Use Cases ¡ A Use Case always has a single starting point. ¡ A Use Case doesn’t always have one finishing point: a Use Case is finished when the goal is achieved or abandoned. ¡ There are three kinds of scenarios, describing: ¡ Normal (error-free) use of the system – the “happy days” scenario ¡ Uses where errors occur but that can be dealt with as part of the interaction process (for example, entering invalid data) ¡ Uses where errors occur but that cannot be dealt with as part of the normal processing (exceptions) Techniques for Analysing and Specifying Requirements: Use Cases ¡ To write a Use Case use a template. ¡ See Chapter 5, pages 34 to 37 of Daoust, N. (2012). UML Requirements Modeling for Business Analysts: Steps to Modeling Success. EBSCOhost. for a template including instructions. ¡ For an example see pages 37 to 40.  Techniques for Analysing and Specifying Requirements: Use Cases ¡ Typical step types include: ¡ Initial step is typically taken by the initiating ¡ The system requesting the actor to provide actor. data ¡ Some are triggered by time ¡ The actor providing data to the system ¡ Final step is always taken by the system ¡ The system validating data ¡ The system performing a calculation ¡ Steps can be repeated: ¡ The system presenting the result to the actor ¡ eg, the customer continues adding items to their ¡ The system retrieving data from another shopping cart until they indicate that they actor wish to proceed to pay ¡ The system storing the data it received from an actor  Techniques for Analysing and Specifying Requirements: Use Cases ¡ Extensions: ¡ some condition occurs in a Use Case, is detected, and then a series of alternate steps are followed to resolve the situation. ¡ Extensions may result in success (alternate flows) ¡ Extensions may result in failure (failure situations) ¡ The final step usually returns to a step in the main success scenario Techniques for Analysing and Specifying Requirements 1. Scenarios 2. User Stories 3. Use Case Diagrams 4. Use Cases Techniques for Analysing and Specifying Requirements After requirements are gathered, analyse and document them accurately. 3. Other Formal Methods Apart from use cases, other formal methods like entity-relationship diagrams and state transition diagrams are used for specifying complex requirements, especially related to data models and system behavior. Writing High-Quality Requirements Writing high-quality requirements is essential for the success of any software development project. 1. Characteristics of High-Quality Requirements: clear, consistent, complete, and testable. Clear requirements are easy to understand, leaving no room for ambiguity. Consistent requirements ensure that there are no conflicts or contradictions. Complete requirements cover all aspects of the system's functionality, leaving no gaps. Testable requirements are specific and verifiable, allowing for proper validation and verification. 2. Involving Stakeholders in Review and Validation: The involvement of stakeholders in the review and validation of requirements is crucial to ensure accuracy and alignment with their needs. Regular feedback from stakeholders helps to identify potential issues and improving the requirements. Stakeholders can validate whether the requirements meet their expectations and fulfill the intended objectives. Prioritising and Managing Requirements Requirements in software development are dynamic and subject to change. It is important to prioritise them based on their significance and manage changes effectively to ensure project success 1. Requirements Change: Requirements are not static; they evolve throughout the project lifecycle. Stakeholder feedback and changing market conditions often lead to changes in requirements. To be able to manage changing requirements they need to be prioritised. Prioritising and Managing Requirements 2. Prioritising Requirements: Assessing each requirement's value, complexity, and potential impact on the software system. Requirements can be categorised into 'must-have,' 'should-have,' and 'nice-to-have' based on their importance. By Prioritising requirements, development teams can ensure that essential features are delivered early, reducing the risk of project delays and cost overruns. A well-managed process needs to be adopted so that all changes are documented, evaluated, and approved by relevant stakeholders. Requirements Validation and Verification Requirements validation and verification are essential processes in software development to ensure that the specified requirements accurately represent stakeholders' needs and expectations. 1. Requirements Validation: The process of checking that the specified requirements align with stakeholders' actual needs. It involves evaluating whether the stated requirements will address the intended problem or opportunity. Validation ensures that the development team is building the right product that will meet the stakeholders' expectations. It involves engaging stakeholders throughout the process to gather feedback and validate that the requirements accurately capture their needs. 2. Requirements Verification: The process of reviewing and checking the specified requirements for consistency, completeness, and correctness. It involves confirming that the requirements are clear, unambiguous, and free of contradictions. Verification ensures that the requirements can be implemented and tested effectively. This weeks reading ¡ Chapter 4 & 5 (Use Case Models) from: Daoust, N. (2012). UML Requirements Modeling for Business Analysts: Steps to Modeling Success. EBSCOhost. up next: part B: CSS fundamentals