Software Requirements Analysis Exam Notes PDF

1. What is a requirement in software development? **Answer:** A requirement is a condition or capability needed by a user to solve a problem or achieve an objective. It is a statement that must be true for the system to be considered successful. 2. Why are requirements important? **Answer:** Requ...

1. What is a requirement in software development? **Answer:** A requirement is a condition or capability needed by a user to solve a problem or achieve an objective. It is a statement that must be true for the system to be considered successful. 2. Why are requirements important? **Answer:** Requirements are crucial because they serve as the foundation for system design and development, align the project with stakeholder expectations, and reduce the risk of project failure. 3. What are the main types of requirements? Answer: Functional Requirements: Define specific behaviors or functions of the system (what the system should do). Non-Functional Requirements: Define quality attributes of the system (how the system should perform). User Requirements: High-level statements of what users need from the system. System Requirements: Detailed specifications of the system's functions and constraints. 4. What are the key activities in the requirements engineering process? Answer: Requirements Elicitation: Gathering requirements from stakeholders. Requirements Analysis: Evaluating and prioritizing requirements. Requirements Specification: Documenting the requirements clearly. Requirements Validation: Ensuring documented requirements reflect stakeholder needs. Requirements Management: Handling changes to requirements throughout the project lifecycle. 5. What techniques are used for requirements elicitation? Answer: Interviews: One-on-one discussions with stakeholders. Surveys/Questionnaires: Collecting data from a larger audience. Workshops: Collaborative sessions with multiple stakeholders. Prototyping: Creating mock-ups of the system to visualize requirements. 6. What is the difference between requirements validation and verification? Answer: Validation: Ensures that the right product is being built (meets stakeholder needs).  Verification: Ensures that the product is being built correctly (meets specified requirements). 7. What are common challenges in requirements analysis? Answer: Ambiguity: Vague requirements can lead to misunderstandings. Incomplete Requirements: Missing information can cause delays and increased costs. Stakeholder Conflicts: Differing priorities among stakeholders can complicate the process. Scope Creep: Uncontrolled changes in project scope can derail timelines and budgets. 8. What should a requirements specification document include? Answer: Functional Requirements: Detailed descriptions of system functions. Non-Functional Requirements: Quality attributes and constraints. Use Cases: Scenarios describing how users will interact with the system. 9. How can requirements be documented effectively? Answer: Use clear and concise language, organize requirements logically, and include traceability information to link requirements to their sources. 10. What is the significance of traceability in requirements management? **Answer:** Traceability links requirements to their sources, ensuring accountability and helping to manage changes effectively throughout the project lifecycle. //////2 IEEE/EIA 12207 and Related Standards Overview IEEE/EIA 12207 and IEEE 830-1998 both set requirements for documents that describe software requirements. Annex B of IEEE 830 explains how these two sets of requirements relate to each other. Compliance with both standards may be necessary for customers when they request proposals or issue calls for tenders. Requirements Specifications IEEE 830-1998 Standard: Focuses on software requirements specifications. ISO/IEC 12207: Provides a framework for software life cycle processes. ISO/IEC/IEEE 29148:2011:  o Title: Systems and software engineering — Life cycle processes — Requirements engineering. o This standard offers a comprehensive approach to managing requirements throughout the life cycle of systems and software. o It harmonizes IEEE 830, SWEBOK, and seven other standards. Key Features of ISO/IEC/IEEE 29148:2011 Emphasizes: o Characteristics of good requirements. o Requirements engineering activities and processes. o Operations and their context. o Different information items, including their structures. Complies with: o ISO/IEC 15288 o ISO/IEC 12207 Stakeholder Requirements Specification Outline Provides a structured approach to documenting stakeholder requirements. System Requirements Specification Outline Details the requirements specific to the system being developed. Software Requirements Specification Outline Focuses on the requirements specific to the software component. Verification This section outlines the verification methods and approaches planned to qualify the software. Recommended to present verification information in parallel with the information items in section 3. Tutorials and Tools Useful resources for understanding and applying these standards: o PlantUML o Visual Paradigm Software Requirements Analysis Course Requirements Specification Document Clearly describes essential requirements:  o Functions o Performance o Design constraints o Quality attributes Defines the scope and boundaries of the system/software. Each requirement must be feasible and verifiable by methods like: o Inspection o Demonstration o Analysis o Test Serves as a basis for contractual agreements between contractors/suppliers and customers. Elaborated from elicitation notes. IEEE 830-1998 Standard Title: "IEEE Recommended Practice for Software Requirements Specifications." Describes content and qualities of a good Software Requirements Specification (SRS). Provides sample SRS outlines. Objectives of IEEE 830-1998 Helps customers accurately describe their needs. Aids suppliers in understanding customer requirements. Assists in developing templates for SRS in organizations. Facilitates the creation of SRS quality checklists and writer’s handbooks. Benefits of IEEE 830-1998 Establishes agreement between customers and suppliers on software functionality. Reduces development effort and later redesign. Provides a basis for realistic cost and schedule estimates. Supports validation and verification processes. Facilitates software product transfer to new users or machines. Serves as a basis for enhancement requests. Considerations in IEEE 830-1998 Section 4 discusses how to produce a good SRS. Focus on:  o Functionality o Interfaces o Performance o Qualities o Design constraints Emphasizes the need for change management and prototyping. Should focus on external behavior, not design and production processes. Structure of the SRS (Section 5 of IEEE 830) 1. Introduction 2. Overall Description 3. Specific Requirements 4. Additional Information (appendices and index) Section 1 of SRS Describe the purpose of the SRS. Identify the intended audience and the software product. Enumerate system capabilities and limitations. Define vocabulary and list referenced documents. Section 2 of SRS Present the business case and operational concept. Describe external interfaces and constraints. Summarize major functional capabilities. Section 3 of SRS Specify software requirements in detail: o External interfaces o Functions o Performance requirements o Design constraints o Quality attributes Requirements should be: o High quality o Cross-referenced to their source o Uniquely identifiable  o Organized for readability. Templates (Annex A of IEEE 830) Section 3 may be organized based on: o Modes o User classes o Concepts (object/class) o Features o Stimuli and responses o Functional hierarchy. Relationship of IEEE 830 and ISO/IEC 12207 ISO/IEC 12207 provides a common framework for software life cycle processes. ///3 Software Requirements Analysis Exam Study Notes Martha can’t write requirements because… She doesn’t know what to do! She was not taught at school. She doesn’t know how to write. She doesn’t understand the process. She doesn’t have the necessary data. She doesn’t know what she wants. She doesn’t understand why! She doesn’t understand the impact/changes. She thinks this is “just a document.” She’d rather do something else! She’d rather design – she sees no reward. She doesn’t have enough time. She thinks the review process will catch the errors. Anatomy of a Good User Requirement Identifies the system and a desired end result that is measurable within a specified time. Example:  o The Online Banking System shall allow the Internet user to access her current account balance in less than 5 seconds. ▪ Defines the system under discussion. ▪ Uses a verb with correct identifier (shall). ▪ Defines a positive end result. ▪ Includes quality criteria. Example of a Bad User Requirement The Internet User quickly sees her current account balance on the laptop screen. o Cannot write a requirement on the user. o No identifier for the verb. o Vague quality criteria. o Focuses on what versus how. Standard for Writing a Requirement 1. Each requirement must form a complete sentence. 2. Contains a subject and predicate. o Subject: a user type or the system under discussion. o Predicate: a condition, action, or intended result. 3. Use verbs like “shall” for mandatory and “may” for optional. 4. Provides specifics of a desired end goal or result. 5. Contains a success criterion or measurable indication of quality. Key Words for Requirement Levels (IETF RFC 2119) MUST, REQUIRED, SHALL: absolute requirement. MUST NOT, SHALL NOT: absolute prohibition. SHOULD, RECOMMENDED: advisable but not mandatory. SHOULD NOT, NOT RECOMMENDED: advisable against. MAY, OPTIONAL: truly optional. Characteristics of a Good Requirement Feasible (not wishful thinking). Needed (provides specifics of a desired end goal). Testable (contains a success criterion). Clear, unambiguous, precise, one thought. Prioritized.  Identified (ID). Writing Pitfalls to Avoid Over-specification: Describe what the system is supposed to do, not how. Premature Design: Avoid using names of components or technical terms in user/system requirements. Mixing Requirements: Do not mix different kinds or levels of requirements. Ambiguity: Avoid vague terms and ensure clarity. "What versus How" Test Example of a bad requirement: o The system shall use Microsoft Outlook to send an email to the customer with the purchase confirmation. Good requirement: o The system shall inform the customer that the purchase is confirmed. Avoiding Let-out or Escape Clauses Avoid terms like if, but, when, except, unless, although. These can create ambiguity and problems in testing. Avoiding Vague Indefinable Terms Terms like user-friendly, highly versatile, flexible, etc., are too vague to be verified. Example of a bad requirement: o The EasyEntry System shall be easy to use and require a minimum of training except for the professional mode. Keeping Requirements Simple Each requirement should be a single sentence. Avoid conjunctions (and, or, with, also). Do not ramble or reference unreachable documents. Avoiding Speculation No room for “wish lists” or vague generalizations. Avoid suggestions that are not explicitly stated as requirements. Invariably Ignored by Developers Danger Signs Words to watch for:  o may o might o should o ought o could o perhaps o probably Avoid wishful thinking: o Wishful thinking means asking for the impossible, such as: ▪ $100%$ reliable ▪ Safe ▪ Handle all failures ▪ Fully upgradeable ▪ Run on all platforms The Easy Entry System may be fully adaptable to all situations and often requires no reconfiguration by the user. A Few Simple Tests Test 1: "What versus how" Example: A requirement may specify an ordinary differential equation that must be solved, but it should not mention that a fourth order Runge-Kutta method should be employed. Test 2: "What is ruled out" Does the requirement actually make a decision? o If no alternatives are ruled out, then no decision has really been made. o Example: A requirement may be already covered by a more general one. Test 3: "Negation" If the negation of a requirement represents a position that someone might argue for, then the original decision is likely to be meaningful. o Example: The software shall be reliable. Towards Good Requirements Specifications (1) Valid (or “correct”): Expresses actual requirements. Complete: Specifies all the things the system must do (including contingencies) and all the things it must not do.  o Conceptual Completeness (e.g., responses to all classes of input). o Structural Completeness (e.g., no TBDs!!!). Consistent: Does not contradict itself (satisfiable) and uses all terms consistently. o Note: Inconsistency can be hard to detect, especially in concurrency/timing aspects and condition logic. Formal modeling can help. Beneficial: Has benefits that outweigh the costs of development. Towards Good Requirements Specifications (2) Necessary: Doesn’t contain anything that isn’t “required”. Unambiguous: Every statement can be read in exactly one way and clearly defines confusing terms (e.g., in a glossary). Uniquely identifiable: For traceability and version control. Verifiable: A process exists to test satisfaction of each requirement. o “Every requirement is specified behaviorally”. Understandable (clear): E.g., by non-computer specialists. Modifiable: Must be kept up to date! Typical Mistakes Noise: The presence of text that carries no relevant information to any feature of the problem. Silence: A feature that is not covered by any text. Over-specification: Text that describes a feature of the solution, rather than the problem. Contradiction: Text that defines a single feature in a number of incompatible ways. Ambiguity: Text that can be interpreted in $≥2$ different ways. Forward reference: Text that refers to a feature yet to be defined. Wishful thinking: Text that defines a feature that cannot possibly be validated. Jigsaw puzzles: Distributing requirements across a document and then cross- referencing. Inconsistent terminology: Inventing and then changing terminology. Putting the onus on the development staff: Making the reader work hard to decipher the intent. Writing for the hostile reader: Fewer of these exist than friendly ones. Key Questions and Characteristics Remember the key questions: “Why?” or “What is the purpose of this?” o Feasible  o Needed o Testable Rate these Requirements 1. Invoices, acknowledgments, and shipping notices shall be automatically faxed during the night, so customers can get them first thing in the morning. 2. The Order Entry system provides for quick, user-friendly and efficient entry and processing of all orders. 3. Changing report layouts, invoices, labels, and form letters shall be accomplished. 4. The system shall be upgraded in one whack. 5. The system has a goal that as much of the IS data as possible be pulled directly from the T&M estimate. Somewhat Improved Requirements 1. The system shall automatically e-mail all invoices between $1$ am and $4$ am to the corresponding customers. 2. The Order Entry shall provide entry of all orders on one screen with less than $5$ clicks. 3. Changing report layouts, invoices, labels, and form letters shall be accomplished. 4. The system shall be upgraded by one DevOps with experience of at least $1$ year in $5$ minutes with maximum allowed downtime of $30$ seconds between $4$ and $5$ AM. A Few Syntactic Analysis Tools QuARS: Quality Analyzer of Requirements Specification. Link ARM: Automated Requirement Measurement Tool. Link TIGER Pro: Tool to Ingest and Elucidate Requirements. Link Problem Analysis Goal: Gain a better understanding of the problem being solved before development begins. o Identify root cause. o Identify stakeholders and their needs (or problems). o Identify solution boundary. o Uses business requirements obtained from stakeholders. o Results in Product Vision and Project Scope. Business Requirements / Objectives (1) Business Opportunity: Description of market opportunity, competing market, business problem being solved or improved, advantage of proposed solution. o Example: Exploit the poor security record of a competing product.  Business Objective and Success Criteria: Important business benefits the product will provide in a quantitative and measurable way, how success will be measured, factors that have great impact on success. o Examples: Achieve positive cash flow on the product within $6$ months; Get $50%$+ of the market. Business Risks: Major risks associated with developing or not developing the product (marketplace competition, timing, user acceptance, implementation issues). o Can be modeled with GRL. Business Requirements (2) Important for: o Ensuring that all project participants work for the same reasons. o Getting stakeholders agreement on requirements. o User and software requirements. Problem Analysis Understanding Root Causes There is often a problem behind the problem. Root cause analysis involves finding underlying causes that may not be immediately apparent. Determine recursively what factors contribute to the problem. Example: Problem: Our e-commerce site is not profitable. o Why is it not profitable? ▪ Poor site design? ▪ Bad pricing? ▪ Poor customer management after the sale? ▪ Some or all of the above? Addressing Root Causes Root causes do not all have the same impact. Some may not be worth fixing immediately. Estimate the relative impact of root causes (e.g., using a Pareto chart): o 20% of causes → 80% of problems.  Create a problem statement for the root cause identified as worth solving (and with a computer solution). Product Vision and Project Scope Product Vision: Describes what the product is about and what it could eventually become. o Aligns all stakeholders in a common direction. Project Scope: Identifies what portion of the ultimate long-term product vision the current project will address. o Draws a boundary between what is in and what is out. Project Scope Examples: Project Scope for release 1.1 Project Scope for release 1.0 Project Scope for release n... Vision Statement Vision Statement Template: For [target customer] Who [statement of the need or opportunity] The [product name] Is [a product category] That [key benefit, compelling reason to buy or use] Unlike [primary competitive alternative, current system, or current business process], Our product [statement of primary differentiation and advantages of the new product]. Example: For scientists who need to request containers of chemicals, the Chemical Tracking System is an information system that will provide a single point of access to the chemical stockroom and vendors. The system will store the location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each container's location and usage. This system will save the company 25% on chemical costs in the first year of use by allowing the company to fully exploit chemicals that are already available within the company, dispose of fewer partially used or expired containers, and use a single standard chemical purchasing process. Unlike the current manual ordering processes, our product will generate all reports required to comply with government regulations that require the reporting of chemical usage, storage, and disposal. Vision Statement (Enterprise Level) uOttawa Vision (2010):  We aspire to be, among universities, the essential reference on what Canada represents: a university that is an integral part of its community, open to the world, and distinguished by its search for excellence in research, its high-quality learning environment, its passion for knowledge and innovation, its leadership on language issues, and its openness to diversity. Every member of our institution will take part in our educational mission. uOttawa Vision (Today): The University of Ottawa will offer an unparalleled university experience and, through outstanding teaching and research, play a vital role in defining the world of tomorrow. We will instil in each of our graduates an ethic of service, a culture of engagement, and an awareness of shared responsibility that will prepare them for global citizenship. Dynamic Vision, Scope, and Requirements The product vision may apply to many projects. Views of the customer and the enterprise evolve slowly (e.g., in years). The product scope focuses on one project. o Important to the project manager. o More dynamic than the vision. o Can be part of a requirements document. Requirements focus on what is needed for the product to meet business objectives. o Many and rapid changes! Project Viability – Scope Scope: Product's purpose and the system's boundaries. o How much of the work will be done by the system-to-be-developed? o How much of the work will be done by interacting systems? Information needed for cost and time estimates. Define more precisely the problem to solve. List all the things the system should have to do. Exclude as much as possible to reduce the complexity of the problem. Establish broader goals if the problem is too simple. Example: An automated system for university registration. o Initial list of wide problems: ▪ Exam Schedule ▪ Room Allocation ▪ Payment  ▪ Course Browser ▪ Registration o Reduced scope: ▪ Course Browser ▪ Registration ▪ Later stage: Payment for other systems, Room Allocation, Exam Schedule. Vision and Scope Document Business requirements. Vision of the solution. o Including major features and dependencies. Scope and limitation. o For initial and subsequent releases. Business context. o Including priorities and operating environment. Risks!!! In Summary “The idea is to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system, and decide if it is worthwhile to invest in deeper exploration.” [Craig Larman] Scope Constraints Document Introduction to Requirements Elicitation Requirements elicitation is the process of discovering what is needed for a system by communicating with stakeholders. Elicitation means to bring out or evoke information. It often involves interaction among various people. Goals, Risks, and Challenges Elicitation Goals Identify sources of information and techniques. Gather information on the domain, problems, and constraints. Produce an initial document with user requirements and notes.  o This document may be incomplete or disorganized, but it's a starting point. Elicitation Risks and Challenges 1. Problems of Scope o System boundaries may be poorly defined. o Unnecessary technical details may be included. 2. Problems of Understanding o Stakeholders may not know what they need. o Communication issues can arise. o Stakeholders may not understand the capabilities of the system. o Conflicting requirements can be hard to detect and prioritize. 3. Problems of Volatility o Stakeholders may not commit to written requirements. 4. Other Typical Issues o Experts may not be available. o Stakeholders may resist change. o Finding the right level of detail can be challenging. o Requirements may be hidden or too obvious. Sources of Requirements Various Stakeholders o Clients, customers, users, managers, domain experts, developers, and others who can add value. Pre-existing Systems o Not limited to software; can include any existing documentation or systems. Standards and Policies o Relevant legislation and agreements can also provide requirements. Stakeholder Types 1. Customer/Client o Pays for the software and has the final say on the product. 2. Buyer o Purchases the software and must be involved in the project. 3. User o Current or future users who provide insights on necessary functions.  4. Domain Expert o Knowledgeable about the specific field the software addresses. 5. Software Engineer o Understands technology and feasibility of the project. 6. Others o Inspectors, market research specialists, and lawyers who can provide additional insights. On Stakeholders Availability Stakeholders are often busy and may see participation as an extra task. Support from managers is crucial for successful elicitation. It's important to avoid being seen as a threat to their roles or responsibilities. Tasks Elicitation Problems Requirements Elicitation Tasks Tasks Performed as Part of Elicitation (1) Planning for the elicitation o Why? o Who? o When? o How? o Risks? During the elicitation o Confirm the viability of the project (is it worth it?) o Understand the problem from the perspective of each stakeholder o Extract the essence of stakeholders’ requirements o Invent better ways to do the work of the user Following the elicitation o Analyze results to understand obtained information o Negotiate a coherent set of requirements acceptable by all stakeholders and establish priorities o Record results in the requirements specification Tasks Performed as Part of Elicitation (2) Repeat as needed o Elicitation is incremental o Driven by information obtained Continuous Process o You always do a bit of elicitation – analysis – specification – verification at the same time Elicitation Plan – Objectives / Strategies & Processes Objectives: Why this elicitation? o Validate market data o Explore usage scenarios o Develop a set of requirements, etc. Set elicitation strategies and processes o Approaches used ▪ Often a combination of approaches depending on the types and number of stakeholders ▪ Examples: Surveys (questionnaires), workshops, interviews Elicitation Plan – Products Usually set of rough requirements o Written, audio, video notes o Documentation Deliverables depend on objective and technique o Generally: unorganized, redundant, incomplete Extract Essence Extract the essence of the stakeholders' requirements o Interpret stakeholders' descriptions of requirements o Possibly build models (may be part of your documentation!) o Gaps in the model behavior may indicate unknown or ambiguous situations o Models help focus our efforts o Should be resolved by asking the stakeholders (especially users) Invent Better Ways Invent better ways to do the user's work  o Ask why documented requirements so far are desired o The client/user’s view can be limited by past experiences o Brainstorm to invent requirements the stakeholders have not yet thought of Dilbert on Requirements Elicitation Humorous take on the challenges of requirements elicitation ////4 Elicitation Techniques Stakeholder Analysis: Identify and understand the needs of all stakeholders. Analysis of Existing Systems: Review current systems to identify strengths and weaknesses. Discourse Analysis: Examine language used in communication. Task Observation and Ethnography: Observe users in their environment to understand their tasks. Questionnaires: Collect data through structured questions. Interviewing: Engage in discussions to gather detailed information. Brainstorming: Generate ideas collaboratively. Joint Application Design (JAD): Involve stakeholders in the design process. Prototyping: Create preliminary models to visualize requirements. Pilot System: Test a small-scale version of the system. Use Cases and Scenarios: Describe how users will interact with the system. Risk Analysis: Identify potential risks in the project. Comparison of Data-Gathering Techniques 1. Questionnaires o Good for: Specific questions o Data Type: Quantitative and qualitative o Pros: Reach many people, low cost o Cons: Design is crucial, low response rate possible 2. Interviews o Good for: Exploring issues o Data Type: Mostly qualitative o Pros: Guided discussion, builds rapport  o Cons: Time-consuming, may intimidate interviewees 3. Focus Groups and Workshops o Good for: Collecting multiple viewpoints o Data Type: Mostly qualitative o Pros: Highlights consensus and conflict o Cons: Dominant characters may skew results 4. Naturalistic Observation o Good for: Understanding user context o Data Type: Qualitative o Pros: Insight into actual work o Cons: Time-consuming, large data volume 5. Studying Documentation o Good for: Learning procedures and standards o Data Type: Quantitative o Pros: No user time commitment o Cons: May be outdated or incorrect Analysis of Existing Systems Purpose: Improve new systems by understanding existing ones. Key Questions: o What features are used or missing? o What works well or poorly? o How is the system used versus how it was intended to be used? Review Available Documentation Start with: o User documents (manuals, guides) o Development documents o Requirements documents o Internal memos o Change histories Note: Documentation may be outdated or incorrect. Observation and Related Techniques Observation: Watch users perform tasks to gather insights.  Ethnography: Study social and human factors affecting requirements. Supplementing Observation: Use questionnaires and interviews for deeper insights. Ethnography Overview Originates from anthropology, focusing on understanding work culture. Aims to make implicit work processes explicit. Useful for discovering real work contexts and complexities. Ethnography Example Observing air traffic controllers revealed: o Controllers often ignore alarms due to annoyance. o Misinterpretation of their behavior led to incorrect conclusions about their preferences. Interviews Preparation: Set clear goals and understand the subject matter. Objectives: o Record information for analysis. o Discover accurate information efficiently. o Reassure interviewees that their input is valued. Process: 1. Planning and preparation 2. Conducting the interview 3. Consolidating information 4. Follow-up Important Note When conducting interviews, ask open-ended questions to uncover real requirements rather than leading questions that may limit responses. For example: o Instead of asking, "Would you like Word 2010 or Excel 2010?" ask, "What tasks do you need to accomplish with software?" Interview Techniques and Elicitation Preparing for the Interview Understand the interviewee: o Work tasks  o Attitude Prepare questions in advance, organized by subject. Organize the environment for an effective interview. Determine how elicitation notes will be taken: o Manually o Audio o Video o By whom Conducting the Interview Make the interviewee comfortable and confident. Be polite and respectful. Adjust your approach based on the interviewee. Be persistent but flexible in achieving your goals. Consider interviewing several people at once to create synergy. Detect political aspects that may influence the conversation. Elicitation Notes Revise and complete notes soon after the interview to avoid forgetting details. Identify inconsistencies and address them in follow-up interviews or emails. Keep all diagrams, charts, and models created during discussions. Be precise and pay attention to terminology: o Use the interviewee’s terminology. o Identify synonyms. o Create a glossary if necessary. Thank participants (e.g., via email) and keep the door open for future interactions. Common Interviewing Mistakes 1. Not interviewing all the right people: o Different points of view from stakeholders are essential. 2. Asking direct questions too early: o Example: Instead of asking "How much horsepower do you need?" (direct), ask "How many passengers? How far? How fast?" (indirect). 3. Interviewing one-at-a-time instead of in small groups: o Group discussions can generate more ideas and reduce individual pressure.  4. Assuming stated needs are exactly correct: o Users may not know what they want; focus on what is needed. Start Up Questions 1. Context-free questions: o Identify customers, goals, and benefits. o Who is behind the request for the system? o Who will use the system? Willingly? o Are there several types of users? o What is the potential economic benefit from a successful solution? o Is a pre-existing solution available from another source? 2. Prioritization and constraints: o When do you need it by? o Can you prioritize your needs? o What are your constraints (time, budget, resources)? 3. Characterizing the problem: o What would be a "good" solution? o What problems is the system trying to address? o In what environment will the system be used? o Any special performance issues or constraints? 4. Calibration and tracking questions: o Are you the right person to answer these questions? o Are your answers "official"? If not, whose are? o Is there anyone else I should talk to? 5. Indirect questions: o Are you opposed to the system? o Are you trying to obstruct/delay the system? o Do you feel threatened by the proposed system? Specific Questions 1. Functional requirements: o What will the system do? o Are there several modes of operations? o What kinds of computations or data transformations must be performed?  2. Design Constraints: o Where is the equipment to be located? o Are there any environmental restrictions? o Are there constraints on the size of the system? 3. Interfaces: o Is input coming from one or more other systems? o Is there a prescribed way for input/output formatting? 4. Performance: o Are there constraints on execution speed or response time? o How much data will flow through the system? 5. Usability and Human Factors: o What kind of training will be required for each type of user? o How easy should it be for a user to understand the system? Elicitation Techniques Existing Systems Interviews o Specific questions to ask during interviews include: ▪ Security ▪ Must access to the system or information be controlled? ▪ Should each user's data be isolated from data of other users? ▪ Should user programs be isolated from other programs and from the operating system? ▪ Should precautions be taken against theft or vandalism? ▪ Reliability and Availability ▪ Must the system detect and isolate faults? ▪ What is the prescribed mean time between failures? ▪ Is there a maximum time allowed for restarting the system after failure? ▪ How often will the system be backed up? ▪ Must backup copies be stored at a different location?  ▪ Should precautions be taken against fire or water damage? ▪ Maintainability ▪ Will maintenance merely correct errors, or will it also include improving the system? ▪ When and in what ways might the system be changed in the future? ▪ How easy should it be to add features to the system? ▪ How easy should it be to port the system from one platform (computer, operating system) to another? ▪ Precision and Accuracy ▪ How accurate must data calculations be? ▪ To what degree of precision must calculations be made? More on Interviews Watch for unanswerable questions, e.g., "How do you tie your shoelaces?" See interesting video: YouTube Video “Ignorance is bliss” 1. According to Dan Berry, ignorance of a domain is a good thing! o Ignorance (not stupidity) allows one to expose hypotheses and some implicit facts. o Berry suggests that one day, requirements engineers may advertise their domains of ignorance to find a job. o A mix of domain experts and domain ignorant on a team is beneficial. Questionnaires Questionnaires and Surveys Benefits: o Can reach multiple people, maybe in an anonymous way. o Asynchronous, distributed, and can be quick to answer. o Cheap. Challenges: o Preparation time. o Choice of questions: open-ended and close (lack of flexibility). o Choice of answers and scales (nominal, intervals, Likert); avoid centralist tendencies. o Statistical significance during analysis.  o Validity of questions (bias, ambiguities). o Repetition and order of questions. o Determining suitable participants to invite (risk of bias, fraud). o Getting people to answer everything (exhaustion, unattractive). Types of Questions to Consider 1. Demography questions (for classification) o Age, country, occupation for analysis from many angles. o Beware of re-identification risks if supposed to be anonymous. 2. Attitudinal questions o What do you think of…? Do you agree with…? o Scale with 4-6 values (no center) or 5-7 values (with neutral value): 1. Strongly agree 2. Agree somewhat 3. Neither agree nor disagree (Undecided) 4. Disagree somewhat 5. Strongly disagree 3. Supplementary open questions o Instructive, but qualitative. 4. Optional/alternative questions o By population. 5. Redundant questions o For robustness. Analysis to Consider… In Advance! Will the survey be repeated (before/after, for comparison)? Determine the type of (statistical) analysis, e.g.: o Statistical significance? Statistical Significance Test your questionnaire and your analysis on a small group. See also this important video on surveys and questionnaires: YouTube Video Brainstorming Brainstorming To invent new ways of doing things or when much is unknown. When there are few or too many ideas.  Early on in a project particularly when: o Terrain is uncertain. o There is little expertise for the type of applications. o Innovation is important (e.g., novel system). Two main activities: 1. The Storm: Generating as many ideas as possible (quantity, not quality) – wild is good! 2. The Calm: Filtering out of ideas (combine, clarify, prioritize, improve) to keep the best one(s) – may require some voting strategy. Brainstorming – Objectives Hear ideas from everyone, especially unconventional ideas. Keep the tone informal and non-judgemental. Keep the number of participants “reasonable” – if too many, consider a “playoff” type filtering and invite back the most creative to multiple sessions. Encourage creativity. Choose a good, provocative project name. Choose a good, provocative problem statement. Get a room without distractions, but with good acoustics, whiteboards, colored pens, provide coffee/donuts/pizza/beer. Provide appropriate props/mock-ups. Brainstorming – Roles Scribe o Write down all ideas (may also contribute). o May ask clarifying questions during the first phase but without criticizing. Moderator/Leader o Cannot be the scribe. o Two schools of thought: traffic cop or agent provocateur. ▪ Traffic cop: enforces "rules of order", but does not throw his/her weight around otherwise. ▪ Agent provocateur: traffic cop plus more of a leadership role, comes prepared with wild ideas and throws them out as discussion wanes. Brainstorming – Participants Virtually any stakeholder, e.g.: o Developers  o Domain experts o End-users o Clients o “Ideas-people” – a company may have a special team of people. Brainstorming – The Storm Goal is to generate as many ideas as possible. Quantity, not quality, is the goal at this stage. Look to combine or vary ideas already suggested. No criticism or debate is permitted – do not want to inhibit participants. Participants understand nothing they say will be held against them later on. Scribe writes down all ideas where everyone can see (e.g., whiteboard, paper taped to wall). Ideas do not leave the room. Wild is good! Feel free to be gloriously wrong. Participants should NOT censor themselves or take too long to consider whether an idea is practical or not – let yourself go! Brainstorming – The Calm Go over the list of ideas and explain them more clearly. Categorize into "maybe" and "no" by pre-agreed consensus method. Informal consensus. Be careful about time and people. Meetings (especially if creative or technical in nature) tend to lose focus after 90 to 120 minutes – take breaks or reconvene later. Be careful not to offend participants. Review, consolidate, combine, clarify, improve. Rank the list by priority somehow. Choose the winning idea(s). Brainstorming – Eliminating Ideas There are some common ways to eliminate some ideas: o Blending ideas. o Unify similar ideas but be aware not to force fit. Elicitation Techniques Idea Generation and Voting Give each participant $100 to spend on ideas. Apply acceptance criteria prepared prior to the meeting. Eliminate ideas that do not meet the criteria. Use various ranking or scoring methods: o Assign points for criteria met, possibly using a weighted formula. o Vote with a threshold or campaign speeches. o Possibly select top $k$ for voting treatment. Brainstorming and Voting on Ideas Voting with threshold: o Each person is allowed to vote up to $n$ times. o Keep ideas with more than $m$ votes. o Have multiple rounds with smaller $n$ and $m$. Voting with campaign speeches: o Each person is allowed to vote up to $j < n$ times. o Keep ideas with at least one vote. o Have someone who voted for an idea defend it for the next round. o Have multiple rounds with smaller $j$. Brainstorming – Tool Support Brainstorming can be fun and stimulate creativity. Can be done via email, but requires a good moderator to: o Prevent flamers. o Avoid race conditions due to asynchronous communication. o Avoid going into too much detail. Collaboration tools include: o TWiki o BrainStorm o IdeaFisher Joint Application Design (JAD) A structured and intensive brainstorming approach developed at IBM in the 1970s. Involves defined roles and structured activities.  JAD sessions may last a few days. Quote: "The whole is more than the sum of its parts." - Aristotle Joint Application Design – Roles 1. Session Leader: o Organizer and facilitator with good people skills. 2. Analyst: o Produces official JAD documents and understands the big picture. 3. Executive Sponsor: o Manager responsible for the product, provides strategic insights. 4. User Representatives: o Knowledgeable end-users and managers who come prepared with suggestions. 5. Information System Representatives: o Technical experts who help users understand system capabilities. 6. Specialists: o Experts on specific topics like security or UI issues. Challenges of Brainstorming and JAD Sessions Unnatural clusters of uncomfortable participants. Risk of "groupthink". Superficial responses to technical issues. Bias and dominance in discussions. Prototyping A software requirements prototype is a mock-up or partial implementation. Helps clarify and complete requirements. Addresses uncertainties early in the development process. Encourages user participation and mutual understanding. Prototyping – Types Evolutive: Incrementally developed into a product. Throw-away: Focuses on less understood aspects, designed to elicit or validate requirements. Prototyping – Realizations Prototypes can take many forms: o Paper prototypes  o Storyboards o Screen mock-ups o Interactive prototypes using high-level or scripting languages. Prototyping – Fidelity High-fidelity: o Applications that "work" and provide understanding of functionality. o Advantages: Reduces design risk, precise requirements. o Disadvantages: Time-consuming and costly to build. Low-fidelity: o Static prototypes that are easy and quick to build. o Advantages: Engages users early, encourages creativity. o Disadvantages: May not cover all aspects, perceived as non-professional. Developing Use Case Models of Systems Describes interactions between a system and external actors. Developed by Ivar Jacobson. Actors are agents interacting with the system to achieve goals. A use case describes a sequence of actions an actor performs to complete a task. Use Cases Should describe user interaction with the system, not system computations. Covers the full sequence of steps from start to finish. Should include only actions where the actor interacts with the computer. Use Cases – Abstraction Level Should be independent of any particular implementation or user interface design. Essential use cases: Abstract and technology-free. Concrete use cases: Technology/user interface dependent. Scenarios A scenario is an instance of a use case. Case Definition A case expresses a specific occurrence of a use case.  o Involves a specific actor. o Occurs at a specific time. o Uses specific data. Many scenarios can be generated from a single use case description. Each scenario may require multiple test cases. This term is used generically in this course, similar to its use in requirements engineering. Scenarios A use case includes: 1. Primary Scenario ▪ Normal course of events. 2. Secondary Scenarios ▪ Alternative/exceptional course of events, variations of the primary scenario. ▪ Alternative Scenario: Meets the intent of the use case but follows a different sequence of steps. ▪ Exceptional Scenario: Addresses conditions that differ from the norm and cases already covered. Example Primary Scenario: Vote in a session. Alternative Scenario: Voting in several sessions. Exceptional Scenario: Handling a non-registrant who wishes to vote. Types of Scenarios 1. As-is Scenario o Describes the current situation, often used in re-engineering projects. 2. Visionary Scenario o Describes a future system, typically in greenfield engineering and reengineering projects. 3. Evaluation Scenario o User tasks against which the system is evaluated. 4. Training Scenario o Step-by-step instructions guiding a novice user through a system. Use Case-Driven Software Lifecycle Activities Overview Scenarios guide elicitation, analysis, design, and testing. Many scenario-based approaches exist. o Example: XP and other agile methods use user stories to generate tests that guide software design and verification. Developers often cannot speak directly to users; scenarios approximate the “voice of the user.” Representation of Scenarios Various approaches include: o Text (informal, formal). o Diagrams (state, sequence). o Video, animation, comics, storyboards. o Collaborative workshops. Specialized notations include UML (sequence, activity, use case diagrams), Message Sequence Charts (MSC), Live Sequence Charts, and Use Case Maps (UCM). Use Case Diagrams Define system boundaries, actors, and use cases. Structure and relate use cases. Associate actors with use cases using: o Include Relation: Express commonality between different use cases. o Extend Relation: Make optional interactions explicit or handle exceptional cases. o Generalization: Represents several similar use cases. Example of Use Case Diagram Inclusions: Allow reuse of sequences of actions across different use cases. Extensions: Keep the base use case simple while allowing for optional interactions. Use Case Templates Common items in use case templates include: o Identifier: Unique label for reference. o Name: Succinctly states user task (e.g., "Order a product"). o Authors: People who discovered the use case. o Goal: Expected outcome from the actor's perspective. o Preconditions: Requirements before the use case begins.  o Postconditions: State of the system after completion. o Minimal Guarantee: State of the system after completion regardless of outcome. o Primary Actor: Initiates the use case. o Participants: Other actors involved in the use case. Narrative Form A paragraph focusing on the primary scenario and some secondary ones. Useful during initial stakeholder meetings. Case Definition A case expresses a specific occurrence of a use case. o Involves a specific actor. o Occurs at a specific time. o Uses specific data. Many scenarios can be generated from a single use case description. Each scenario may require multiple test cases. This term is used generically in this course, similar to its use in requirements engineering. Scenarios A use case includes: 1. Primary Scenario ▪ Normal course of events. 2. Secondary Scenarios ▪ Alternative/exceptional course of events, variations of the primary scenario. ▪ Alternative Scenario: Meets the intent of the use case but follows a different sequence of steps. ▪ Exceptional Scenario: Addresses conditions that differ from the norm and cases already covered. Example Primary Scenario: Vote in a session.  Alternative Scenario: Voting in several sessions. Exceptional Scenario: Handling a non-registrant who wishes to vote. Types of Scenarios 1. As-is Scenario o Describes the current situation, often used in re-engineering projects. 2. Visionary Scenario o Describes a future system, typically in greenfield engineering and reengineering projects. 3. Evaluation Scenario o User tasks against which the system is evaluated. 4. Training Scenario o Step-by-step instructions guiding a novice user through a system. Use Case-Driven Software Lifecycle Activities Overview Scenarios guide elicitation, analysis, design, and testing. Many scenario-based approaches exist. o Example: XP and other agile methods use user stories to generate tests that guide software design and verification. Developers often cannot speak directly to users; scenarios approximate the “voice of the user.” Use Case Maps (UCM). ///4 Market (to Minimize) Importance of Requirements Granularity It is crucial to agree on the level of detail for requirements. Examples include: o Use cases o Features o Detailed functional requirements Prioritization Techniques 1st Technique – Prioritization Scales Determine criteria, granularity, and scale dimensions. Frequently used dimensions: o Urgency ▪ High: Mission-critical requirement; needed for the next release. ▪ Medium: Supports necessary operations; can wait for a later release. ▪ Low: Functional or quality enhancement; nice to have if resources allow. o Importance ▪ Essential: Product is unacceptable without these requirements. ▪ Conditional: Enhances the product but is acceptable if absent. ▪ Optional: Functions that may or may not be worthwhile. 2nd Technique – Wiegers’ Prioritization A semi-quantitative approach based on value, cost, and risk. Dimensions to consider: o Relative benefit (value of having the requirement) o Relative penalty (impact on stakeholders if absent) o Relative cost (cost to implement) o Relative risk (technical and other risks) Each dimension is scored on a scale (e.g., 0 to 9). Formula for overall priority: $ \text{priority} = \frac{\text{value%}}{(\text{cost%} \times \text{cost weight}) + (\text{risk%} \times \text{risk weight})} $ Limitations include the need for accurate estimation and adaptation. 3rd Technique – Volere Prioritisation Uses an editable Excel document to score requirements based on various factors. Example factors include: o Value to Customer (40%) o Value to Business (20%) o Minimize Implementation Cost (10%) o Ease of Implementation (30%) Each requirement is scored, and total weights are calculated. 4th Technique – Pairwise Comparisons A method to compare requirements directly (A vs. B).  Benefits: o Highlights what is important to the client. o Identifies high-value, low-cost requirements (priority). o Identifies low-value, high-cost requirements (likely to be removed). Challenges include the large number of pairs to compare, which can be managed using transitivity and optimization techniques. 5th Technique – Analytic Hierarchy Process (AHP) Developed by Karlsson and Ryan, based on Saaty's work. Uses cost-value diagrams for analyzing candidate requirements. Basic procedure: 1. Develop a pairwise comparison matrix for criteria. 2. Normalize the matrix. 3. Average the values of each row for ratings. 4. Use ratings to evaluate potential decisions. Basic Rating Procedure Pairwise comparison rating scale uses values like 2, 4, 6, or 8 for preferences. Example: o Comparing two products based on cost and quality. o If Product A costs $60 and is above average quality, while Product B costs $15 and is average quality, the matrix will show a strong preference for Product B. Conclusion Prioritization is essential in requirements management. Various techniques can be employed to ensure that the most critical requirements are addressed effectively. Software Requirements Analysis Exam Study Notes Requirements Triage and Negotiation Requirements Negotiation (1) Conflicts may arise among stakeholders, including: o Supplier vs. customers regarding costs, benefits, and risks. o Power struggles within the customer organization. o Conflicts with other projects over resources.  o Conflicting goals, features, and requirements. Conflict resolution involves negotiation. Requirements analysts must: o Detect inconsistencies in requirements. o Facilitate understanding among stakeholders. o Reach a coherent agreement that satisfies as many stakeholders as possible. Requirements Negotiation (2) 1. Detect inconsistencies in requirements. 2. Encourage stakeholders to understand each other's perspectives. 3. Have each party explain their understanding of the other's needs. 4. Reach an agreement on a coherent set of requirements that supports everyone's goals. Let Schedule Drive Requirements Typical Scenario: o "Here are our requirements. By when can you build them?" o "It will take us 9 months." o "Sorry, they must be completed in 6 months." Better Scenario: o "We will build in 3-month increments. Here are all the requirements." o Discuss which requirements can be prioritized or dropped to meet deadlines. Requirements Negotiation – Key Aspects (1) Territory: Desired requirements. Map: Requirements document, an abstract model of intentions. Interpretation: Each stakeholder views requirements differently. Importance of clarity and precision in documentation. Requirements Negotiation – Key Aspects (2) Negotiating Boundaries: Stakeholders' reactions to requirements indicate their openness to compromise. Helps optimize requirements for all stakeholders. Difficulties (1) Too many requirements from various sources. Limited resources (budget, time). Establishing priorities is crucial:  o Which requirements are important? o How to prioritize them? o Developers may not understand business value; clients may not grasp implementation complexity. Difficulties (2) Different stakeholders have varying goals and priorities. Some stakeholders' decisions carry more weight. Lack of systematic data and metrics for prioritization. Prioritization often done informally and ad-hoc. Requirements Prioritization and Triage Prioritization (or triage) is essential to determine which requirements matter most. Trade-offs are often necessary (e.g., functionality vs. time/resources). Helps in: o Making acceptable trade-offs among goals. o Allocating resources based on requirement importance. o Deciding when a requirement should be included in the product. 80-20 Rule 20% of functionalities provide 80% of revenues. Example: MS Word. Focus on identifying the most beneficial 20% of functionalities. Requirements Triage Process Must be simple and fast for industry adoption. Should yield accurate and trustworthy results. Considerations include: o Maximizing the value of requirements to stakeholders. o Minimizing the cost of implementation. o Time to market. Analysis Triage/Prioritization Basic Rating Procedure (4) Normalize the matrix  o First, add up all the values in each column. o Next, divide the values in each column by the corresponding column sums. Note: The values in each column add up to 1. Basic Rating Procedure (5) Average the value of each row to get the corresponding rating. Analytic Hierarchy Process – Steps Requirements engineers check individual requirements for ambiguities, completeness, etc. Apply AHP’s pairwise comparison to estimate the relative value of candidate requirements. Experienced software engineers use AHP’s pairwise comparison to estimate the cost of candidate requirements. Plot these values on a cost-value diagram. Stakeholders use this diagram for analysis and to make trade-offs. Analytic Hierarchy Process – Example (1) Introduction to examples of AHP in practice. Analytic Hierarchy Process – Example (2) Cost-value diagram representation. Analytic Hierarchy Process – Stakeholders (1) Each client is unique! Each stakeholder group may have a different weight. The process uses a weighting criteria to consider each individual stakeholder group. o Example: Stakeholders M1 to M10 represent different markets. ▪ Revenue from the last release. ▪ Profit from the last release. ▪ Number of sold licenses from the last release. ▪ Predictions of the above criteria for the coming release. ▪ Number of contracts lost to competitors. ▪ Number of potential customers with no licenses to date. ▪ Size of total market segment. ▪ Growth potential. Analytic Hierarchy Process – Stakeholders (2) Before adjustment based on stakeholders' importance.  o Source: Damian, 2005. Analytic Hierarchy Process – Stakeholders (3) After adjustment based on stakeholders' importance. o Source: Damian, 2005. Example of Commercial Tool IBM Rational (formerly Telelogic) Focal Point. o Decision support and portfolio management. o Pairwise comparisons of features. o Creation and validation of web questionnaires. o Dynamic algorithm for reducing the number of pairs according to the responses. o Detection of inconsistency between the answers. o Priorities for different markets represented in various ways. o Integration with DOORS. o IBM Focal Point. Elicitation Techniques Existing Systems Interviews Questionnaires Brainstorming Prototyping Use Cases Use Case Development – Rules of Thumb (3) Keep names and data at an abstract level suitable for users. Input and output events should have intuitive names. Avoid data definition in use cases. Use cases need to be understandable by users; they must validate them. Avoid functional decomposition. Do not structure use cases as nested functions with «includes». Avoid deep hierarchies with «includes». Use Case Development – Rules of Thumb (4) Think of use cases before the use case diagram. Do not spend too much time on the use case diagram; the textual description is the most important part. Avoid excessive use of "extends" and "includes" in use case diagrams. Do not describe the user interface. Limit the number of use cases; if there are too many, you may have included too much detail (“If in doubt, leave it out”). Do not attempt to describe everything; too many variations can complicate the process. The requirements specification captures a more complete picture. Benefits of Use Case-Based Software Development Helps define the scope of the system. Used to plan the development process. Develops and validates the requirements. Simple and easy to create. Understood by all stakeholders. Reflects user's essential requirements. Separates normal behavior from exceptional behavior. Forms the basis for defining test cases. Structures user manuals. Use Cases are Not a Panacea… Use cases must be validated using requirements validation methods. Question and observe many types of users. Some software aspects are not covered by use case analysis. Non-functional requirements integration. Innovative solutions may not be considered. Scalability and maintainability issues. Tools Many UML tools support use case diagrams but may not support use cases well. UCEdtool (Prof. Somé) helps capture/validate use cases: o Use Case edition (structured English) o Domain model edition (and automatic extraction)  o Scenario edition o Use Case & Domain model validation o Use Cases combination in state models o Simulation of executable model derived from Use Cases o Scenario generation o UCEd Tool Link Use Case Edition with UCEd Use Case model (use case, extend, include, actor…) Use Case description and edition area. Don’t be Negative, But… Be ready to face challenges. Some may wish to see you fail. Unforeseen events can occur in any project. Open systems face various threats. Software can contain bugs. Remember Murphy’s Law: “Anything that can go wrong will go wrong.” Think about Negative Scenarios? A negative scenario aims to: o Be undesirable from the business organization’s viewpoint. o Be desirable from a hostile agent’s viewpoint (not necessarily human). Consider them beforehand along with potential solutions. Misuse Case Proposed by Sindre et Opdahl (2000). Captures use cases that a system must be protected against. The goal is to threaten the system. Misuse case’s misactor is a hostile agent. Finding Misuse Cases – Step 1 Start from a normal use case diagram. Identify misactors (hostile roles) who want to: o Harm the system, its stakeholders, or their resources intentionally. o Achieve goals incompatible with the system's goals. Finding Misuse Cases – Step 2  Identify misuse cases. Ask what a misactor would do to harm the system. Express goals of misactors and add relationships (threaten). Finding Misuse Cases – Step 3 Mitigate misuse cases. Ask what would neutralize the threats. New included use case, new extension use case, or new secondary scenario might be added. Benefits and Risks of Misuse Cases Benefits: o Elicitation of security and safety requirements. o Early identification of threats, mitigations, and exceptions that could cause system failure. o Early identification of test cases. o Documentation of rationales. Risks: o Premature design solutions in mitigation. o Missing misactors and threats in a partial view. Tool: DOORS Plug-in Scenario Plus (for Telelogic DOORS): o Textual / Graphical output (HTML). o Automatic links, metrics, etc. o Automatic creation of use/misuse cases upon referencing. o Automatic creation of links between misuse and use cases. Conflict and Trade-off Analysis New relations: aggravates and conflicts with. Use Cases for 'Web Portal Security': o Threatens, includes, mitigates, aggravates. Introduction to Requirements Analysis What is Requirements Analysis? o The process of studying and analyzing customer and user needs to define the problem domain and system (including software) requirements. o Analysis goes hand-in-hand with modeling. Objectives of Requirements Analysis 1. Detect and resolve conflicts between (user) requirements. 2. Negotiate priorities of stakeholders. 3. Prioritize and triage requirements. 4. Elaborate system requirements to be documented in the requirement specification. Requirements Interoperability Requirements Ensure systems can work together seamlessly. Ethical Requirements Address moral implications of the system. Legislative Requirements Comply with laws and regulations. Implementation Requirements Define how the system will be built and deployed. Standards Requirements Adhere to industry standards. Delivery Requirements Specify how and when the system will be delivered. Safety Requirements Ensure the system operates safely. Privacy Requirements Protect user data and privacy. Product Requirements Define the features and functionalities of the product. Organizational Requirements Align with the organization's goals and processes. External Requirements Consider requirements from outside the organization. Non-functional Requirements  Focus on how the system performs rather than what it does. Introduction to Requirements Specification Software Quality Classifications of NFRs Non-functional requirements (NFRs) are essential for assessing software quality. Quality Measures Quality measures help evaluate the effectiveness of NFRs. Interesting Resources on Wikipedia ISO/IEC 9126: Software engineering — Product quality o ISO/IEC 9126 "ilities": Various quality attributes o "Ilities" Software Quality: How to measure it o Software Quality ISO/IEC 9126 Qualities This standard is increasingly replaced by ISO/IEC 25000:2005, which focuses on software product quality requirements and evaluation (SQuaRE). Quantification Non-functional requirements need to be measurable. Avoid subjective terms like good or optimal. Values should have a rationale and be understood by stakeholders. Important to rank and prioritize requirements. Precise numbers may not be known initially; negotiate later. Measures vs. Metrics Measures: General observations. Metrics: Specific measurements. o Example: ▪ Metric: mean time between failures. ▪ Measure: 23 days between failures. Performance Measures (1) Various performance measures include: o Response time o Number of events processed/denied  o Throughput o Capacity o Latency Can be modeled and simulated for performance prediction. Performance Measures (2) Examples of performance requirements: 1. The system shall process 100 payment transactions per second at peak load. 2. CPU usage shall be less than 50% under standard workload. 3. A simple report shall take less than 20 seconds for 95% of cases. 4. Scrolling in a 200-page document shall take at most 1 second. Reliability Measures (1) Measures the system's performance during requests. Important for critical systems. Can be measured using: o Defect rate o Precision of computations. Reliability Measures (2) Examples: 1. The precision of calculations shall be at least $1/10^6$. 2. The system defect rate shall be less than 1 failure per 1000 hours of operation. Availability Measures (1) Definition: Percentage of time the system is operational. Calculated using: o Mean-Time to Failure (MTBF) o Mean-Time to Repair (MTTR) Formula: $ \text{Availability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} $ Availability Measures (2) Examples: 1. The system shall meet or exceed 99.99% uptime. 2. The system shall not be unavailable more than 1 hour per 1000 hours of operation. 3. Restart time after a failure shall be less than 20 seconds for 95% of the time. Security Measures (1) Measures include: 1. Resistance to unauthorized usage. 2. Service continuity during denial of service attacks. Measurement methods: o Success rate in authentication. o Time/resources needed to find a key. Security Measures (2) Examples of requirements: 1. The application shall identify all client applications before allowing access. 2. At least 99% of intrusions shall be detected within 10 seconds. Usability Measures (1) Focus on ease of use and training for end users. Specific measures include: o Learnability o Efficiency o Memorability o Error avoidance. Usability Measures (2) Examples: 1. The system should enable at least 80% of users to book a guest within 5 minutes after a 2-hour introduction. 2. Novice users shall perform tasks X and Y in less than 15 minutes. 3. Expert users shall perform tasks X and Y in less than 2 minutes. Introduction to Requirements Specification Software Quality Classifications of NFRs Quality Measures Satisfaction Level: The system should achieve a "very good" satisfaction level or better for at least 80% of customers after 3 months of usage. Maintainability Measures (1)  Definition: Measures the ability to make changes quickly and cost-effectively. Aspects: o Extension with new functionality o Deleting unwanted capabilities o Adaptation to new operating environments (portability) o Restructuring (rationalizing, modularizing, optimizing, creating reusable components) Measurement Metrics: o Coupling/cohesion metrics o Number of anti-patterns o Cyclomatic complexity o Mean time to fix a defect o Mean time to add new functionality o Quality/quantity of documentation Tools: Code analysis tools such as IBM Structural Analysis for Java. Maintainability Measures (2) Examples of Requirements: 1. Every program module must be assessed for maintainability according to procedure XYZ. ▪ 70% must obtain “highly maintainable” and none “poor”. 2. The cyclomatic complexity of code must not exceed 7. 3. No method in any class may exceed 200 lines of code. 4. Installation of a new version shall leave all database contents and personal settings unchanged. 5. The product shall provide facilities for tracing any database field to places where it is used. Testability Measures Definition: Measures the ability to detect, isolate, and fix defects. Aspects: o Time to run tests o Time to set up testing environment (development and execution) o Probability of visible failure in presence of a defect o Test coverage (requirements coverage, code coverage)  Examples: o The delivered system shall include unit tests that ensure 100% branch coverage. o Development shall use regression tests allowing for full retesting in less than 12 hours. Portability Measures Definition: Measures the ability of the system to run under different computing environments. Aspects: o Hardware, software, OS, languages, versions, combination of these Measurement Metrics: o Number/Enumeration of targeted platforms o Proportion of platform-specific components or functionality o Mean time to port to a different platform Example: No more than 5% of the system implementation shall be specific to the operating system. Integrability and Reusability Measures Integrability: Measures the ability to make separated components work together. o Expressed as mean time to integrate with a new interfacing system. Reusability: Measures the ability that existing components can be reused in new applications. o Expressed as percentage of reused requirements, design elements, code, tests, etc. Robustness Measures Definition: Measures the ability to cope with the unexpected. Aspects: o Percentage of failures on invalid inputs o Degree of service degradation o Minimum performance under extreme loads o Active services in presence of faults o Length of time for which the system is required to manage stress conditions Examples: o The estimated loss of data in case of a disk crash shall be less than 0.01%.  o The system shall be able to handle up to 10,000 concurrent users when satisfying all their requirements and up to 25,000 concurrent users with browsing capabilities. Domain-specific Measures Note: Quality measures may vary by application domain. o Performance: ▪ Web-based system: Number of requests processed per second. ▪ Video games: Number of 3D images per second. o Accessibility: ▪ Web-based system: Compliance with standards for the blind. ▪ Video games: Compliance with age/content ratings systems (e.g., no violence). Other Non-Functional Requirements Considerations: NFRs like “fun,” “cool,” “beautiful,” or “exciting” may not be easily measurable. Approach: It may be better to let customers brainstorm before proposing conventional NFR categories. Goal: Refine those goals into measurable requirements. Dilbert on Quality Source: Material from various authors and resources. Requirements Modelling with UML History of UML Source: Wikipedia and other resources. Key Figures: Jacobson, Rumbaugh, Booch. Diagram Types in UML 2.x Structural Diagrams: Class, object, composite structure, component, and use case diagrams. Dynamic Diagrams: State machine, activity, sequence, communication, timing, and interaction overview diagrams. Physical Diagrams: Deployment diagrams. Model Management: Package diagram. Most Relevant for Requirements Engineering Use Case Diagram: Use cases structuring. Class Diagram: Domain modeling.  Activity Diagram: Workflow and process modeling. Sequence Diagram: Modeling of message exchange scenarios. State Machine Diagram: Detailed behavioral specification. Entity-Relationship Modeling (ERM) Concepts: o Entity: Represents a type of entity instances, defining properties for all instances. o Relationship: Represents relationship instances between entity instances. o Multiplicity: Indicates how many instances of one side may relate to a given instance of the other side. o Attribute: An entity or relationship may have attributes identified by name and type. Attribute Type Introduction Overview of various diagrams used in object-oriented analysis and design. Key diagrams include Class Diagram, Activity Diagram, Sequence Diagram, and State Machine Diagram. ERM – Notations Different notations have been used for Entity-Relationship Models (ERM). Chen’s notation is one of the notable examples. Methodology for Object-Oriented Analysis (OOA) Five main steps in OOA: 1. Identify core classes within the problem domain. 2. Model relationships between classes (Class Diagram). 3. Define attributes associated with each class. 4. Determine relevant operations for each class. 5. Define messages that may be passed between objects (Interaction Diagram, State Machine Diagram). Problems with Class Diagrams (1) Caution: OOA is not always analysis; many approaches focus on high-level design. Class diagrams can be useful for analysis, especially for domain concepts. Issues include:  o Composition and decomposition problems. o Related requirements may not fit into a single component or class. o One scenario may impact multiple classes. o Object-oriented modularization is imperfect, leading to scattering and tangling effects. Problems with Class Diagrams (2) Scattering: Design elements supporting a requirement (R1) are spread across many components. Tangling: A single component contains elements for multiple requirements (R1, R2, R3, etc.). Aspect Triggered behavior (code) and predicates. Partial solution involves aspects, which identify join points for advice execution. Activity Diagrams Basic Notational Elements of Activity Diagrams Describe dynamic behavior as a flow of activities (workflow). Key elements include: o Flow o Sequence o Alternative o Parallel Note: Data flow objects may be represented as boxes on control flow lines. Partitions – Examples Used to organize activities within the diagram. Unique to Activity Diagrams Data flow modeling. Conditions on parallelism (AND-fork branches). Integration with UML, including class diagrams and OCL. Sequence Diagrams Basic Notational Elements of Sequence Diagrams Describe dynamic behavior as interactions between participants (agents, actors, system components). Each participant has a "lifeline." Lifelines and (A)synchronous Interactions Participants interact by sending/receiving messages. Messages can be either synchronous or asynchronous. Combined Fragments Allow representation of multiple sequences compactly. Operators include: o alt: Alternatives with conditions. o opt: Optional behavior. o loop(lower bound, upper bound): For loops. o par: For concurrent behavior. o critical: For critical sections. o break: To indicate a scenario not covered. o assert: Required condition. o ignore/consider: For filtering messages. o neg: For invalid scenarios. o strict or seq: For sequencing. o ref: For referencing other sequence diagrams. Combined Fragments – Alternative alt operator allows multiple operands with guard conditions. One operand is chosen exclusively. Combined Fragments – Optional opt operator specifies a guarded behavior fragment with no alternative. Combined Fragments – Loop loop operator allows execution multiple times based on guard conditions. Combined Fragments – Concurrency par operator allows two or more operands to execute in parallel. Concurrency Quiz – Part One! Valid sequential traces must maintain the defined ordering for each operand. State Machine Diagram Basic Notational Elements of State Machine Diagrams Describe the dynamic behavior of an individual object through states and transitions. Types of State Machines  UML allows mixing of Moore and Mealy automata. o Moore Automaton: Outputs depend only on states. o Mealy Automaton: Outputs depend on states and inputs. Variables (“Extended” States) Example: ctr := ctr + 1 where ctr is an integer. Modeling Behavior State machines are suitable for reactive systems based on events. Not suitable for continuous systems (e.g., spacecraft trajectory control). State Machine Diagram Summary Ready: o stop/ctr := 0 stop State: o Trigger: Action o Initial Pseudostate o Transition o Final State: Done o Composite State Entry and Exit Actions LampOn: o Entry: lamp.on(); o Exit: lamp.off(); Resulting action sequence: o printf(“exiting”); o printf(“to off”); o lamp.off(); Action Ordering Output actions: transition prefix Input actions: transition postfix o Example:  ▪ printf(“exiting”); ▪ printf(“needless”); ▪ lamp.off(); ▪ off/printf(“needless”); ▪ off/printf(“to off”); State Activities (Do) Creates a concurrent process that will execute until: o The action terminates, or o We leave the state via an exit transition Example: do/alarm.ring() Guards (Conditions) Conditional execution of transitions Guards must not have side effects o Example: ▪ Selling: ▪ Unhappy: bid [(value >= 100) & (value < 200)] /sell ▪ Happy: bid [value >= 200] /sell ▪ Reject: bid [value < 100] /reject Hierarchical State Diagrams Composed states to manage complexity o Example: ▪ LampFlashing: ▪ flash/ 1sec/ 1sec/ ▪ FlashOff: Entry: lamp.off() ▪ FlashOn: Entry: lamp.on() ▪ LampOff: Entry: lamp.off() ▪ LampOn: Entry: lamp.on() Completion Transition Triggered by a completion event Automatically generated when an embedded state machine terminates o Example: ▪ Committing:  ▪ Phase1 ▪ Phase2 ▪ CommitDone ▪ Completion transition (without trigger) Triggering Rules Many transitions can share the same triggering event When leaving, the most deeply embedded one takes precedence The event disappears whether it triggers a transition or not Action Ordering – Composite States Example: o S1 exit/exS1 o S11 exit/exS11 o S2 entry/enS2 o S21 entry/enS21 o Action sequence on transition E: ▪ exS11 → exS1 → actE → enS2 → initS2 → enS21 Orthogonal Regions Combine many concurrent perspectives Interactions across regions typically done via shared variables o Example: ▪ Child, Adult, Retiree: ▪ Age ▪ Financial Status: Poor, Rich Semantics of Orthogonal Regions All mutually orthogonal regions detect the same events and respond simultaneously (possibly interleaved) o Example: ▪ robBank/ Conclusion Understanding state machine diagrams is crucial for modeling complex systems and their behaviors effectively. Introduction Importance of Traceability (1) Requirements cannot be managed effectively without requirements traceability. A requirement is traceable if: o You can discover who suggested it. o You understand why it exists. o You know what requirements are related to it. o You can see how it relates to other information (e.g., system designs, implementations, user documentation). Importance of Traceability (2) Benefits of traceability include: o Prevents losing knowledge. o Supports the verification process (certification, localization of defects). o Aids in impact analysis. o Facilitates change control. o Enables process monitoring (e.g., missing links indicate completion level). o Improves software quality (ensures changes are made correctly and completely). o Assists in reengineering (defining traceability links records reverse engineering knowledge). o Promotes reuse (identifying what goes with a requirement: design, code, etc.). o Reduces risk (e.g., if a key team member leaves). Traceability Difficulties Various stakeholders require different information. A huge amount of requirements traceability information must be tracked and maintained. Manual creation of links is very demanding and often frustrating. Specialized tools must be used. Integrating heterogeneous models/information from different sources (requirements, design, tests, code, documentation, rationales) is complex. Requires organizational commitment and understanding of potential benefits. Backward and Forward Traceability (1) Backward traceability: Refers to previous stages of development. o Depends on each element explicitly referencing its source in earlier documents.  Forward traceability: Refers to all documents spawned by a document. o Depends on each element having a unique name or reference number. Backward and Forward Traceability (2) From a requirements perspective: o Forward-to traceability: Links other documents to relevant requirements, aiding validation and evaluating changes. o Forward-from traceability: Links requirements to design and implementation components, ensuring all requirements are satisfied. Backward and Forward Traceability (3) From a requirements perspective (continued): o Backward-to traceability: Links design and implementation components back to requirements, helping determine design/implementation reasons. o Backward-from traceability: Links requirements to their sources in other documents or people, aiding validation and evaluating impact on stakeholders. Types of Traceability (1) Requirements – source traceability: Links requirements with a person or document. Requirements – rationale traceability: Explains the reasoning behind requirements. Requirements – requirements traceability: Links requirements with other dependent requirements. Requirements – architecture traceability: Links requirements with subsystems where they are implemented. Requirements – design traceability: Links requirements with specific hardware or software components used for implementation. Types of Traceability (2) Requirements – interface traceability: Links requirements with external system interfaces. Requirements – feature traceability: Connects requirements with specific features. Requirements – tests traceability: Links requirements with test cases that verify them. Requirements – code traceability: Generally inferred rather than directly established. Representation – Traceability Table Shows relationships between requirements or between requirements and other artifacts. Can be set up to show links between different elements. Captures both backward and forward traceability. Difficult to capture different types of links. Representation – Traceability Matrix Defines links between pairs of elements (e.g., requirements to requirements, use case to requirement). Can specify relationships (e.g., specifies/is specified by, depends on). More amenable to automation than traceability tables. Representation – Traceability List Traceability matrices can become large and sparsely populated with many requirements. A simplified traceability matrix may be used, maintaining lists of related requirement identifiers alongside each requirement description. What are Suspect Links? Indicate elements that may have been affected by changes.