CSE-862 Requirement Engineering Classification of Requirements & Documentation Standards

Review of the previous lecture Agenda Review of the previous lecture Requirements Classification Requirements Organization and Documentation Quality of RE documents

Review of the previous lecture: What are Requirements?

Steps of Requirements Development Capture the requirements Analyze, distill and record the requirements Model requirements Validate the resulting Requirements Specification With the project team for completeness and understanding With the client for accuracy and validity Output: Software Requirements Specification Document

Requirements Classification Agenda Review of the previous lecture Requirements Classification Requirements Organization and Documentation Quality of RE documents

Requirements Types

Functional vs. Non-Functional Requirements describe what the system should do Non-Functional Requirements: global constraints on a software system functionality

Functional Requirements Describe the functionality or services that the system is expected to provide Address the input-output behavior of a system

Example of Functional Requirement {FR1} Software shall automatically detect the presence of other computers running the application that are connected to the network.

Non-Functional Requirements NFRs Non-functional requirement = system quality attribute – For the user: performance, usability, reliability – For the developer: portability, interoperability, maintainability – For the owner: cost, benefit • Challenge: Subjective Relative

Write Quantifiable NFRs: Quantifiable = Testable NFRs should be stated in measurable terms. Compare: An operator shall not have to wait for the transaction to complete… change to measureable An operator shall not have to wait more than 1s for a transaction to complete for at least 95% of the transactions. Interesting phenomenon: What gets measured gets done.

Examples of NFRs

Design Constraints

Design Constraints Design constraints typically originate from one of three sources: Restriction of design options – “Use Oracle DBMS” Conditions imposed on the development process – “Should be compatible with legacy inventory system” or “"The application must run on both our new and old platforms" Regulations and imposed standards - For example, the development of a medical product in the United States is subject to a significant number of Food and Drug Administration standards and regulations or “ISO”

FURPS+ Classification for requirements other than FR Functional System-wide functionality which is architecturally significant Non-Functional (NFRs): These requirements can be grouped in 4 categories Usability Human factors, help, documentation, etc. Reliability Frequency of failure, recoverability, availability.. Performance Response time, throughput, capacity… Supportability: Supportability is the ability of the software to be easily modified to accommodate enhancements and repairs Maintainability, adaptability, configurability, etc.

FURPS+ Classification Cont. + indicates additional constraints such as: Design Constraints i.e. requiring a relational database Interface constraints i.e. protocols for interaction with external systems Implementation Constraints Required standards, platform, implementation language Physical constraints Shape, size, weight.

FURPS+ Classification Examples "The product will be localized (support multiple human languages)“. FURPS+ Type? “F” architecturally significant functional requirement. "The persistence will be handled by a relational database" FURPS+ Type? “+” design constraint. "The database will be Oracle 8i" FURPS+ Type? “+” implementation constraint. "The system will run seven days a week, twenty-four hours per day" FURPS+ Type? “R” reliability requirement. "An online help system is required" FURPS+ Type?

Requirements Organization and Documentation. Agenda Requirements Classification Requirements Organization and Documentation. IEEE Std.830 UP Quality of RE documents

Requirements Specification Standards IEEE 830-1998 IEEE recommended practice for software requirements specifications Volere Requirements Specification Template, Edition 13—August 2007 by James & Suzanne Robertson

Requirements Specification Standard (Will be practiced in Project) Which one to practice? IEEE 830-1998 IEEE recommended practice for software requirements specifications OR Volere ? Your choice! Focus on using an

IEEE Std 830-1998 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements

IEEE Std 830-1998 (Template A5) Section 3.1 External interfaces Section 3.2 Functional requirements (system features) Section 3.3 Performance requirements Section 3.4 Logical database requirements Section 3.5 Design constraints Section 3.6 Software system attributes Section 3.7 Other requirements

Volere Requirements Specification Template, Edition 13—August 2007 Project Drivers 1. The Purpose of the Project 2. The Client, the Customer, and Other Stakeholders 3. Users of the Product Project Constraints 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions Functional Requirements 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements

Volere Requirements Specification Template, Edition 13—August 2007 Nonfunctional Requirements 10. Look and Feel Requirements 11. Usability and Humanity Requirements 12. Performance Requirements 13. Operational and Environmental Requirements 14. Maintainability and Support Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements Project Issues 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room

Use-Case Requirements Artifacts Vision An executive summary of the project Use-Case Model A set of typical scenarios of using the system (functional requirements) Supplementary Specification Captures and identifies other kinds of requirements such as non-functional requirements & design constraints. Glossary Captures terms and definitions; also play the role of a data dictionary Business Rules Long-living rules or policies (e.g., tax laws) for this particular application

UP Main Artifacts Glossary

Vision Document

Delta Vision Document

Supplementary Specification: content Functional requirements not expressed in use cases reports Non-functional requirements Quality attributes of the system Legal, regulatory and documentation requirements Design constraints Interfaces Business Rules

Organizing Requirements for Nested Systems Develop a product-family Vision document showing how the products are intended to work together use cases showing how the users will interact with various applications running together. common software requirements specification that defines the specific requirements for shared functionality (menu structures and communication protocols). For each product in the family, develop a Vision document, software requirements specification, and a use-case model

Requirements Organization for Nested Systems

Supplementary Specification: Non-Functional Requirements for Quality Usability the ease with which the system can be learned and operated by the intended users. (required training time, task times for typical tasks, conformance to usability standards) Example: The customer will be able to see a large-monitor Therefore: Text should be easily visible from 1 meter. Avoid colors associated with common forms of color blindness.

Supplementary Specification: Requirements for Quality Reliability Availability (% of time the system is expected to be available) Allowed MTBF, MTTR Definition for defects’ criticality level Maximum defect rate allowed per KOLC Example (Recoverability) If there is failure to use external services (payment authorizer, accounting system, ...) try to solve with a local solution (e.g., store and forward) in order to still complete a sale.

Supplementary Specification: Requirements for Quality Performance Average, maximum response time for a transaction number of customers/transactions the system can accommodate Example: Buyers want to complete sales processing very quickly. One bottleneck is external payment authorization. Our goal: authorization in less than 1 minute, 90% of the time.

Supplementary Specification: Requirements for Quality Supportability Coding standards naming conventions Class libraries … Example: Adaptability Different customers of the NextGen POS have unique business rule and processing needs while processing a sale. Therefore, at several defined points in the scenario (for example, when a new sale is initiated, when a new line item is added) pluggable business rule will be enabled.

Supplementary Specification: Constraints Example: NextGen leadership insists on a Java technologies solution, predicting this will improve long-term porting and supportability, in addition to ease of development.

Supplementary Specification: Interfaces Noteworthy Hardware and Interfaces Touch screen monitor (this is perceived by operating systems as a regular monitor, and the touch gestures as mouse events) Barcode laser scanner (these normally attach to a special keyboard, and the scanned input is perceived in software as keystrokes) Software Interfaces For most external collaborating systems (tax calculator, accounting, inventory, ... ) we need to be able to plug in varying systems and thus varying interfaces.

Supplementary Specification: Business Rules

More on Requirements for Quality: Exercise Which of the following quality attributes: efficiency, reliability, usability, maintainability would be important for the system computing income taxes, that will be used by government employees who audit taxpayers?

Requirements for Quality: Exercise Which attributes of quality efficiency, reliability, usability, maintainability would be important for the system computing income taxes, that will be used by government employees who audit taxpayers? Answer: Income tax software is an application domain in which maintainability will be a big concern since tax regulations tend to change frequently. Usability will also be important so the auditors can do their job efficiently. Reliability will be of moderate importance (accuracy of results, however , will be very important) . Efficiency will be of minimal importance .

Quality of RE documents Agenda Review of the previous lecture Requirements Classification Requirements Organization and Documentation Quality of RE documents

Desirable Properties of Requirements & Specifications: IEEE Std

Validating Requirements Artifacts Completeness: All possible behavior through the system are described, including exceptional behavior by the user or the system Correctness: The requirements represent the client’s needs Consistency: There are no functional or nonfunctional requirements that contradict each other Unambiguity: Exactly one system is specified, it is not possible to interpret the requirements in two or more ways. feasability: Requirements can be implemented and delivered Traceability: the ability to find corresponding or related information in other documents or software

Quality of Requirements: Correctness Each requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as an actual customer or a higher level system requirements specification. Only user representatives can determine the correctness of user requirements.

Quality of Requirements: Unambiguity Unambiguous. The reader of a requirement statement should be able to draw only one interpretation of it. Natural language is highly prone to ambiguity Effective ways to reveal ambiguity include: formal inspections of the requirements specifications, writing test cases from requirements creating user scenarios that illustrate the expected behavior of a specific portion of the product.

Quality Requirements Specifications: Completeness Completeness: All possible behavior through the system are described, including exceptional behavior by the user or the system Graphical analysis models that represent different views of the requirements can also reveal incompleteness. If you know you are lacking certain information, use “TBD” (“to be determined”) as a standard flag to highlight these gaps.

Quality Requirements Specifications: Consistency Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements. Inconsistencies can slip in undetected if you review only the specific change and not any related requirements.

Quality of Requirements: Verifiable See whether you can devise tests or use other verification approaches, such as inspection or formal specification, to determine whether each requirement is properly implemented in the product. Requirements that are not consistent, feasible, or unambiguous also are not verifiable.

Quality Requirements Specifications: Modifiability Each requirement be uniquely labeled and expressed separately from other requirements so you can refer to it unambiguously. Organizing requirements so that related requirements are grouped together Create a table of contents, index, and cross-reference listing; traceability matrices

Quality Requirements Specifications: Traceability Traceability is the ability to link each software requirement to its source, which could be a higher-level system requirement, a use case, or a voice-of-the-customer statement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs or bullet lists.

Example of a Traceability Matrix   UC 1 UC 2 Suppl. Req. 1 … Feature 1 X Feature 2 Feature 3 Feature n

Important! Feasibility It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a developer work with the requirements analysts or marketing personnel throughout the elicitation process.

Key Points: Role of Requirements Engineer

Exercise 1 “The product shall provide status messages at regular intervals not less than every 60 seconds.” Quality Analysis?

Desirable Properties of Requirements & Specifications: IEEE Std

Exercise 1: Improved

Exercise 2 “The product shall switch between displaying and hiding non-printing characters instantaneously.” Analysis?

Exercise 2: Improved “The user shall be able to toggle between displaying and hiding all HTML markup tags in the document being edited with the activation of a specific triggering condition.”

Exercise 3 “Charge numbers should be validated on-line against the master corporate charge number list, if possible.” Analysis?

Exercise 3: Improved “The system shall validate the charge number entered against the online master corporate charge number list. If the charge number is not found on the list, an error message shall be displayed and the order shall not be accepted.”

Key Points Goals of managing and documenting requirements in SE: To fix requirements errors in RE phase To ensure that the RE documents describe THE product the, customer really wants To ensure the RE documents are correctly understood by the customer and the developers

Root Causes of Requirements management challenges Lack of User Input Incomplete requirements & specifications Changing requirements and specifications

RE IQ Question Why developers often fail to write & manage requirements? “Even if we’re not really sure of the details of what we want, it’s better to get started with implementation now because we’re behind the schedule and in a hurry. We can pin down the requirements later”. Does it sound familiar? …

RE is a Team Work RE work requires well-structured and well-trained software teams Requires Team Skills to understand user needs to manage the scope of the application To build systems that meet those needs

Next? Analyzing the Problem (Team Skill 1)