Requirements Engineering - Software Specification Document - PDF

Requirements Engineering Building Usable Software 2024-2025 Recap 1. Planning 4. Implementation - Problem Transform - Features requirements into - Users code. 2. Analysis 5. Testing Gathered Softwar...

Requirements Engineering Building Usable Software 2024-2025 Recap 1. Planning 4. Implementation - Problem Transform - Features requirements into - Users code. 2. Analysis 5. Testing Gathered Software meets - Analyzed requirements and - Documented is free of bugs. - Prioritized 3. Design 6. Maintenance Architecture Update, modify, and styles/design improve after patterns deployment. The software is designed, implemented, and tested Requirements Engineering Models incrementally (a little more is added each time) until the product is finished. It divides the system into smaller Requirements parts and prioritizesWaterfall them for gradual implementation. Architecture Incremental Deliver A linear and sequential Increments approach, where each phase must be completed Feedback before the next one begins. Feedback Emphasizes iterative Fuses the iterative development development, flexibility, and process of prototyping with the Focuses on breaking down the project customer satisfaction. Involves systematic aspects of the Waterfall into component parts, each developed regular communication with model, emphasizing risk analysis at in isolation. Prioritizes reuse of stakeholders and continuous each spiral/iteration. components across different projects. improvement at every iteration. Spiral Component-Based (CBSE) Agile Main differences among models Characteristics Waterfall Spiral Prototyping Agile Flexibility --- +++ Risk Management +++ User Involvement --- +++ +++ Development --- --- +++ +++ Speed Class Activity: Soft. Process Model Software System Model E-Commerce Website Agile Space Exploration Software Spiral Hospital Management System Incremental Gaming Engine Component-based Room booking system Waterfall  Class Activity 1: Soft. Process Model System Model Interactive travel planning Answer: Incremental – Agile system that helps users plan Rationale: System with a complex user interface but which must journeys with the lowest be stable and reliable. An incremental development approach is environment impact. the most appropriate as the system requirements will change as real user experience with the system is gained. System to control anti-lock Answer: Waterfall braking in a car. Rationale: This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. Requirements Engineering Learning Objectives Explain the differences between user and system requirements. Describe the process of engineering requirements. Explain the differences between Functional and Non-functional requirements. Analyze how software requirements may be organized in a requirement specification document. Requirements Engineering Process Process of establishing what services are required and the constraints on the system’s operation and development. Elicitation: Identify sources. Specification: Classify requirements, model, top-level architecture, negotiate req. Validation: Reviews, prototypes, modelling, test definition, etc. Documentation: Requirement, specification, standard, quality. What are Software Requirements? Description of the system services and constraints, generated during the requirements engineering process. Range from high-level abstract statements of a service or of a system constraint to a low-level detailed specification. General Rule Abstract (General) → refine (more detailed and specific). The library system shall be always available. The library system shall be available 24/7.​ Requirements: “General” Statements The system will maintain records of all library items including books, serials, newspapers, magazines and videos. No item shall be removed from the library without the details of its borrowing being recorded in the system​. All items shall have a digital barcode containing a unique reference number. Could the “general” statements help us to understand how the system should work and interact with the user, other systems, and the environment? Sources of Requirements Stakeholders: Application domain: - Decision-makers General area where the system is - End-users applied. Problem to be solved: - System administrators Details of the specific customer - Engineering problem where the system will be - Marketing applied. - Sales Business context: - Customer support How the system interacts and contributes to overall business goals. Goals/Objectives Stakeholder needs and Broad, long-term achievable constraints: Specific needs of people who require outcomes / Actionable, system support in their work. measurable actions that achieve the goal. Mentcare System The Mentcare system (Figure 1.6) is a patient information system that is intended for use in clinics. It maintains information about patients suffering from mental health problems and the treatments that they have received. Purposes: 1. To generate management information that allows health service managers to assess performance against local and government targets. 2. To provide medical staff with timely information to support the treatment of patients. Features: Individual care management. Patient monitoring Administrative reporting Stakeholders in the Mentcare System Why Software Requirements are important? “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later” [Fred Brooks in the “Mythical Man Month”] Requirements Engineering Process Software engineers work with stakeholders to Stages discover or capture requirements: Find out about the application domain; Services that the system should provide; Required system performance, hardware constraints, etc. Information about existing systems. Requirements Discovery Collection-based techniques Analysis-based techniques Interviews Prototyping Workshops Documenting Analysis Surveys and Questionaries Use Cases and user stories Job Shadowing Benchmarking Focus Group Brainstorming Requirements Elicitation Techniques Interviews: Prototypes: Open/close (structured/unstructured), Small-scale replica of the facilitated meetings (professional system, mock-up using paper, group work). diagrams or software. Observations: Stories and Scenarios: Observing “real world” work. Stories: High-level description of system use (big picture). Scenarios: Parts of the story in more detail (starting situation; normal flow Revisiting documentation, manual of events; what can go wrong; systems, etc. concurrent activities; state when the scenario finishes). Story: Req. Discovery Scenario: Req. Discovery Requirements Classification Functional: Functions of the software. User Interface: User and interactions with other hardware or software. System features: Functions of the system. Non-Functional: Performance, scalability, security, availability. Functional External & System features Non-Functional User Interface (UI) User and System Requirements User Requirements Abstract statements of the system requirements for the customer and # end-user of the system. System Requirements A detailed description of the functionalities the system is expected to provide to users and the constraints under which it operates. Functional Requirements (FR) High-level statements to describe the functionalities or services the system should provide. - How the system should react to particular inputs - How the system should behave in particular situations May state what the system should not do. FR: Examples Functional Requirement ID Functional Requirement Description FR1 A user shall be able to search the appointment lists for all clinics. FR2 The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. FR3 Each staff member using the system shall be uniquely identified by his or her eight-digit employee number. Note: Each requirement must be implementable. Don’t write the overall aim of the system as a single requirement. Issues in FR Precision: Ambiguous requirements may be interpreted in different ways by developers and users. For instance, “search” in R1. User intention – search for a patient name across all appointments in all clinics. Developers interpretation – search for a patient name in an individual clinic. The user chooses clinic and then searches. Completeness: They should include descriptions of all facilities required. Consistency: There should be no conflicts or contradictions in the description of the services. Non-Functional Requirements (NFR) Define the overall qualities or attributes of the resulting system (e.g., reliability, response time, performance, security, availability, etc.). Constraints or limitations on the services or functionalities offered by the system. May also specify process requirements e.g., a particular IDE, programming language, or development method, standard. NFR are more critical than FR, if they are not met, the system may be useless. [A constraint on how the functional requirements may be implemented]​  Process standards used, Types of NFR implementation requirements, etc. Interoperability req., How will the legislative req., etc.) product behave (execution speed, reliability, etc.)? Types of NFR Product requirements Requirements which specify that the delivered product must behave in a particular way e.g., execution speed, reliability, etc. Organizational Requirements Requirements which are a consequence of organizational policies and procedures e.g., process standards used, implementation requirements, etc. External Requirements Requirements which arise from factors which are external to the system and its development process e.g., interoperability requirements, legislative requirements, etc. NFR: Examples Non-Functional Requirement ID Non-Functional Requirement Description NFR1 Downtime within normal working hours shall not exceed 5 seconds in any one day. (Product requirement) NFR2 Users of the Mentcare system shall identify themselves using their health authority identity card. (Organizational requirement) NFR3 The system shall implement patient privacy provisions as set out in HStan-03-2006-priv. (External requirement) Note: Each requirement must be measurable. Ensure the requirement is relevant to the specific system. NFR: Dimensions of Dependability Metrics for NFR Usability Requirements: Examples The system should be easy to use by medical staff and should be organized in such a way that users’ errors are minimized (Goal). Medical staff shall be able to use all the system functions after hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use (Testable NFR). Class Activity: FR/NFR for Canvas Functional requirements 2.1 User Management User Registration: Canvas shall support user registration for administrators, instructors, students, and other user roles. User Authentication: The system shall provide secure authentication methods, including username and password, and email verification. 2.2 Course Management Course Creation: Instructors shall be able to create and manage courses, including course descriptions, enrollment options, and access controls. Course Content: Instructors shall be able to upload, organize, and manage course materials, such as lectures, assignments, quizzes, and multimedia content. 2.3 Communication …. Class Activity: FR/NFR for Canvas Non-Functional requirements 3.1 Performance Scalability: Canvas shall be scalable to accommodate a large number of concurrent users and courses. Response Time: The system shall maintain fast response times for loading course content and interactive elements. 3.2 Security Data Security: Canvas shall encrypt sensitive user data, protect against unauthorized access, and adhere to data privacy regulations. 3.3 Usability User Interface: Canvas shall provide an intuitive and user-friendly interface for users of all levels of technical expertise. 10 Top Reasons for Not Doing Requirements 1. We don’t need requirements; we are using objects/java/web/ 2. The users don’t know what they want. 3. We already know what the users want. 4. Who cares about what the users want? 5. We don’t have time to do requirements. 6. It’s too hard to do requirements. 7. The problem is too complex to write requirements. 8. It is easier to change the system later than the requirements upfront. 9. We have already started writing code, and we don’t want to change it. Class Activity: FR/NFR The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall allow a strong password of at least 8 characters. The system should provide appropriate viewers for the user to read documents in the document store. The system shall allow up to 100 concurrent users. Requirements Prioritization MoSCoW Criteria Often used in requirements prioritization and as a language for specifying requirements. M: Must have - mandatory requirements that are fundamental to the system (Have). S: Should have – important requirements (Desired). C: Could have – optional requirements​ (Nice to have) W: Won’t have – these requirements really can wait, not priority (i.e. bells and whistles)​ Example: Req. Prioritization Requirements Specification Translating the information gathered during requirements analysis into a document that defines a set of requirements. Natural language sentences: Sentence (#) expresses requirements. Structural natural language: Follow a standard form or template where fields provide specific aspects of the requirements. Graphical models: Use to define functional requirements (e.g., UML use cases and sequence diagrams, etc.) Formal languages (e.g., Abstract State Machines (ASMs); Alloy, B-method, Z- method). Example: Structured Specification Req. Specification: Use Cases Use cases are a kind of scenarios that are described using the Unified Modeling A Language (UML). High-level graphical model supplemented by more detailed tabular description. Includes: Actors: Users or other systems. Use cases: Represented in ellipses. Interaction: Links actors and use cases. Requirement Validation Requirements error costs are high. Discover problems, incompleteness and Fixing a requirement error after delivery inconsistencies in the elicited requirements. may cost up to 100 times the cost of Check that the system meets the user’s needs. fixing an implementation error. Issues Lack of clarity: Natural language is ambiguous and lacks precision. Requirements confusion: FR and NFR tend to be mixed up. Over-flexibility: The same requirement may be described in different ways. Others - inconsistency, missing requirements, stakeholders’ bias, incompleteness, redundancy, irrelevance, and overloaded statements. Requirement Checking Validity. Does the system provide the functions which best support the customer’s needs?​ Consistency. Are there any requirements conflicts?​ Completeness. Are all functions required by the customer included?​ Realism. Can the requirements be implemented given the available budget and technology?​ Verifiability. Can the requirements be checked? Example: Requirement Checking Example 1: R100. The screen allows input of the following information: length, temperature and current time. R100. The screen allows input of the following information: length in meters, the temperature in C, and current time in YYY-MM-DD HH:MM:SS format. Example 2: R1000. The system MUST support a maximum of 10 sensors connected concurrently. R1010. The system response time MUST not exceed 10 ms when 20 sensors are connected to it concurrently. R1000. The system MUST support a maximum of 20 sensors connected to it concurrently. R1010. The REQUIRED maximum system response time in dependency on the number of sensors connected concurrently is shown in Table 1: # Sensors connected Max. Response time (ms) R1000 20 10 R1010 10 5 Software Specification Document Goal of Technical Writing in Specifications A document that defines requirements, functionality, and behavior of a software system. Acts as a communication bridge between stakeholders (e.g., developers, clients, QA teams). Why is it important? Ensures clarity and alignment. Minimizes misunderstandings and costly errors. Software Specification Document Key Goals: Provide clear, unambiguous instructions. Ensure easy comprehension across teams. Document functionality and constraints for future reference. Impact of Poor Writing: Misinterpretation of requirements. Delays and increased development costs. Soft. Specification Document’s Structure Standard Sections: Introduction: Purpose, scope, definitions. System Overview: High-level description of the system. Requirements: Functional and non-functional requirements. Use Cases: User interactions with the system. System Architecture: Components, interfaces, and dependencies. Constraints: Technical, business, or regulatory limitations. Glossary: Define technical terms for clarity. Best Practices in Technical Writing 1. Use Simple Language: Avoid jargon unless absolutely necessary. Write for the intended audience (developers, managers, clients). 2. Be Specific and Unambiguous: Avoid vague terms like "user-friendly" or "fast." Example: "The system will process up to 500 transactions per second." 3. Keep it Organized: Use headings, bullet points, and numbered lists. Follow a logical flow. Writing the Introduction Purpose of the Introduction: Provide an overview of the document's goals. Explain the context of the project and its importance. Define the target audience and stakeholders. Voice & Tense: Use active voice for clarity: "This document outlines..." Use present tense to describe the purpose: "The document serves to..." Writing the System Scope Purpose of the Scope Section: Define what the system includes and excludes. Establish boundaries to manage stakeholder expectations. Voice & Tense: Use active voice for clarity: "The system includes..." Use future tense for planned functionality: "The system will provide..." Use present tense for existing constraints or boundaries: "The system does not..." Writing Functional and Non-Functional Requirements Functional Requirements: Describe what the system should do. Example: "The system shall allow users to reset their passwords via email." Non-Functional Requirements: Describe quality attributes, performance, and constraints. Example: "The system shall support up to 1,000 concurrent users." Tip: Use "shall" for requirements and "should" for recommendations. Writing Functional and Non-Functional Requirements The system shall ….” “The user shall ….” Requirements should be: Specific, unambiguous Measurable, observable, Testable Example : music system - Non-Functional requirements The music player system shall authenticate a user within 5 seconds or less. The system shall load the homepage in under 3 seconds under normal network conditions. The search functionality shall return results within 1 second of a query. Visuals and Diagrams Why Use Visuals? Break down complex ideas. Provide clarity on system flows and architecture. Common Types: UML Diagrams Use Case Diagram: Illustrate user interactions. Class Diagram: Provides a structural view of the system Sequence diagram : Models the flow of interactions in a specific scenario Looking forward to exploring more UML diagrams next weeks! Common Mistakes to Avoid 1. Lack of Clarity: Avoid ambiguous statements. 2. Overloading with Details: Keep it concise; avoid unnecessary explanations. 3. Ignoring the Audience: Tailor the document to the reader's technical proficiency. 4. No Consistency: Maintain uniform terminology, formatting, and style. Key Points Key Points Requirements for a software system set out what the system should do and define constraints on its operation and implementation. FR are statements of the services that the system must provide or are descriptions of how some computations must be carried out. NFR often constrain the system being developed and the development process being used (e.g., product requirements, organizational requirements, or external requirements). The requirements engineering process includes requirements elicitation, requirements specification, requirements validation, and requirements management. Key Points Requirements elicitation is an iterative process that includes requirements discovery, requirements classification and organization, requirements negotiation, and requirements documentation. Requirements specification is the process of formally documenting the user and system requirements. The software requirements document is an agreed statement of the system requirements used by customers and software developers. Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism, and verifiability. Requirements management is the process of managing and controlling changes to the requirements for a software system. Further Readings Read other software engineering case studies. Ian Sommerville. Software Engineering Tenth Edition. Chapter 4: Requirements engineering.