Requirements Engineering

Requirements Engineering

What is a “Requirement”?
The IEEE Standard Glossary of Software Engineering Terminology (1997) defines a requirement as: A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. A documented representation of a condition or capability as in 1 or 2 above. Captures both user’s view and developer’s view

Requirements Engineering
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed Misconception – “Must determine what client wants” Actual – “Must determine what the client needs” The requirements themselves are the descriptions of the system services and constraints that are generated during requirements engineering May range from high-level abstract statement of a service or of a system constraint to a detailed mathematical formal specification Serves multiple purposes Basic for development (e.g. open source project) Basis for a contract itself (must be detailed) Basis for a bid for a contract (must be open-ended)

The Requirements Process
Analysis Requirements Definition Requirements Specification System Models Definition of Requirements Requirements Document Specification of Requirements

Definitions vs. Specifications
Taken from Summerville 2000

Layers of Requirements
User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers

Users of Requirements

Examples of Constraints on Requirements
Regulatory policies Hardware limitations Interfaces to other applications Parallel operation Audit functions Control functions Higher-order language requirements

Types of Requirements (1)
FURPS+ Functional – features, capabilities, security, … Usability – human factors, help, documentation, … Reliability – freq. of failure, recoverability, … Performance – response time, throughput, … Supportability – internationalization, configurability, … “+” Implementation – languages, tools, … Interface – external system interfaces, … Data – required database formats, systems, … Legal - licensing

Functional Requirements Define the fundamental actions that must take place in the software in accepting/processing inputs and generating outputs Validity checks Exact sequence of operations Responses to abnormal situations … Performance Requirements Specify both the static and dynamic numerical requirements placed on the software Number of workstations to be supported Number of simultaneous users Number of transactions per time period

Logical Database Requirements Specify the logical requirements for any data placed in databases Types of information Accessing capabilities Integrity constraints … Standard Compliance Requirements Specify the requirements derived from existing standards or regulations Report formats Data naming Audit tracing

Reliability Requirements Specify the factors that establish the required reliability of the system at time of delivery. Availability Requirements Specify the factors required to guarantee a defined availability Checkpoints Recovery Restart Security Specify factors that protect software from accidental or malicious access

Requirements Terminology
Is “Requirements” the best word? Is each one a “requirement” no matter what? Is there a priority for implementing these? Some now prefer the word “Features” Does not imply that each one has to be implemented Better supports idea of priorities – “features 1 through 10 should be implemented first, then implement features 11 through 20 if there is time…”

Measures for Requirements

Characteristics of Good Requirements
Necessary Good requirements are “must have” requirements Accurate Each requirement must be correct on how it describes the system Straightforward Not subject to misinterpretation Complete Each requirement describes one full result not a partial result Ex: If a field can have two values, specify both in one req Consistent Must not conflict with one another Testable Must be able to validate that the requirement is satisfied Traceable All system artifacts should trace back to requirements

Steps of Requirements Engineering
Elicitation “I ask questions, you talk, I listen” Validation “I analyze, I ask follow-up questions” Specification “I document, I ask follow-up questions” Verification “We all agree”

Elicitation (1) Techniques (1) 1-1 Interviews Group Interviews
Most common Plan ahead Tactics Explain purpose of interview and expectations Answer any upfront questions Confirm time period for interview Allow interviewee to sequence material Document the discussion Group Interviews Limit to two to four people May be subject to “Groupthink” – people together may compromise on requirements

Elicitation (2) Techniques (2) JAD Sessions Prototyping
“Joint Application Development” Get all major stakeholders and knowledge providers together at one time Tactics Identify the correct people Use a facilitator Assign a secretary/note taker Spend the time necessary to reach conclusion/consensus Prototyping Typically an online application that allows the client to visualize the solution Throw prototype away

Validation Consolidating requirements Requirements at different levels
Requirements in different terminology Requirements in conflict Tactics Group into requirements for similar processes Remove false or out-of-scope requirements Place requirements at same level Determine if you have a complete picture Highlight inconsistencies Check that all sources were used Fill-in gaps

Specification Tactics Prioritize the requirements Ensure traceability
Peek ahead at technical details Ensure traceability Document the source of each requirement Develop a traceability matrix More on this later… Ensure testability Create early test cases If doing RUP - create Software Requirements Specification

Verification Hold a requirements review meeting
Include client and team members Can include technical writers Try to catch requirements that are incomplete, vague, untestable, etc. Cover all requirements If concern, modify wording to meet concern If concern is content, move back to stakeholders

Metrics for Requirements Phase
Quality, reliability? Volatility, convergence Changes during subsequent phases Number of times each feature is used Other ideas???

IEEE Requirements Standard (1)
1. Introduction 1.1 Purpose of the requirements document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific requirements 4. Appendices 5. Index This is a generic structure that must be instantiated for specific systems Devil in the details…

IEEE Requirements Standard (2)
My Recommended format for Specific Requirements 3. Specific Requirements 3.1 Functional Requirements 3.1.1 User class 1 Feature 1.1 Feature 1.2 3.2 Performance Requirements 3.3 Design Constraints 3.4 Other Requirements Requirements Specification Template

System Models (1) Several models are developed under traditional approaches like RUP during requirements engineering to help better understand the client and their needs Context Models Behavioral Models Data Models Domain Models Use Cases Models Each takes own perspective on the system Typically of the current system Don’t model non-functional requirements

System Models (2) Context Model
Used to illustrate the boundaries of the system Social and organizational concerns may affect the decision on where to position system boundaries Example: Context Model for an ATM

System Models (3) Data Flow Model Data source/sink External System
A kind of behavioral model Shows flow of information (data) through processing steps/stations Example: Quiz Software Data source/sink External System Data Process

System Models (4) State Transition Model A kind of behavioral model
Show system states as nodes and events as arcs between these nodes Example: Microwave oven

System Models (5) Data Models
Entity-Relationship or Logical Data Structure Diagrams Example: Store

System Models (6) Domain Models (1)
A representation of meaningful concepts in the problem domain Use UML class diagram without methods/details Example: Sale

System Models (7) Domain Models (2) Looking for Conceptual Classes
Do not identify software components Decompose by concepts (objects), not functions. Use vocabulary of the problem, not of the solution Exclude concepts not pertinent to the current iteration (focus) More is better than less Don’t make up concepts (language of problem means your client should recognize it) Don’t exclude concepts without attributes Identify nouns and noun phrases in textual descriptions of the problem domain

System Models (8) Domain Models (3) Top Domain Modeling Errors
Locking in multiplicities on associations right away – realize these may change Assigning operations to classes – this will happen later Debating whether to use aggregation or composition Using hard-to-understand names for classes Creating a one-to-one mapping between domain classes and relational database tables – may persist in different ways Applying design patterns to the domain model – this is a design issue, not a requirements issue

System Models (9) Data Dictionary
Common to have a central repository for the concrete definition of all terms, concepts, objects, etc. in the domain. Frequently combined with a glossary

Requirement Reviews (1)
Organization and Completeness Are all internal cross-references to other requirements correct? Are all requirements written at a consistent and appropriate level? Do the requirements provide an adequate basis for design? Is the implementation priority of each requirement included? Is any necessary information missing from a requirement? If so, is it identified as TBD? Is the expected behavior documented for all anticipated error conditions? Correctness Do any requirements conflict? Is each requirement written in clear, concise, unambiguous language? Is each requirement verifiable? Can all the requirements be implemented within known constraints?

Requirement Reviews (2)
Quality Attributes Are all performance objects properly specified? Are all security and safety considerations properly specified? Traceability Is each requirement uniquely and correctly identified? Special Issues Are all requirements actually requirements, not design or implementation solutions? Are the time-critical functions identified, and timing criteria specified for them? Have internationalization issues been adequately addressed?

Guidelines for Writing Requirements
Keep sentences and paragraphs short Use the active voice Write complete sentences that have proper grammar, spelling, and punctuation Use terms consistently and as defined in the glossary State requirements in a consistent fashion “The system shall” or “The user shall” followed by action verb and observable result Avoid vague terms such as: “user-friendly”, “easy”, “simple”, “rapid”, “efficient”, “support”, “several”, “state-of-the-art”, “superior”, “robust”, and “acceptable” Avoid comparative words Such as “improve”, “maximize”, “minimize”, and “optimize”. Adapted from Wiegers’ “Best Practices for Software Requirements”

Classic Mistakes Fixed (1)
“The product shall provide status messages at regular intervals not less than every 60 seconds” What are the status messages and under what conditions are they “provided”? How long do they remain visible? What part of the “product” are we talking about? Is one per year acceptable? Adapted from Wiegers’ “Best Practices for Software Requirements”

“1. The Background Task Manager (BTM) shall display messages in a designated area of the user interface. 1.1 The messages shall be updated every 60 (+/- 10) seconds after background task processing begins and shall remain visible continuously 1.2 If background task processing is progressing normally, the BTM shall display the percentage of the background task processing that has been completed. 1.3 The BTM shall display a “Done” message when the background task is completed. 1.4 The BTM shall display an error message if the background task is stalled.” Adapted from Wiegers’ “Best Practices for Software Requirements”

“The product shall switch between displaying and hiding nonprinting characters instantaneously.” Not feasible – computers can’t do anything “instantaneously” Doesn’t state cause of switch What is the scope of the display change? Selected text? Entire Document? Are “nonprinting” characters hidden text or are they attribute tags or control characters of some kind? “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 mechanism.” Adapted from Wiegers’ “Best Practices for Software Requirements”

“The parser shall produce an HTML markup error report that allows quick resolution of errors when used by HTML novices.” “quick” is ambiguous What goes into the report? When is the report generated? How would you verify this requirement? “1. After the HTML Parser has completely parsed a file, it shall produce an error report that contains the line number and text of any HTML errors found in the parsed file and a description of each error found. 2. If no parsing errors are found, the error report shall not be produced.” Adapted from Wiegers’ “Best Practices for Software Requirements”

“Charge numbers should be validated online against the master corporate charge number list, if possible.” What does “if possible” means? Technically? Online? What happens if validation passes or fails? Avoid “should” – either it is needed or not “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, the system shall display an error message and the order shall not be accepted.” Adapted from Wiegers’ “Best Practices for Software Requirements”

“The product shall not offer search and replace options that could have disastrous results.” What is “disastrous”? Be careful in describing what the system should not do What is the real intent? Protection from inadvertent damage Multi-level “undo” capability Confirmation of global changes You try it! Adapted from Wiegers’ “Best Practices for Software Requirements”

Sample Application (1) Initial Requirements for Internet Book Store (1) The bookstore shall accept orders via the Internet The bookstore shall maintain a list of accounts for up to 1,000,000 customers The bookstore shall provide password protection for all accounts The bookstore shall provide the ability to search the master book catalog The bookstore shall provide search by author, search by title, search by ISBN number, and search by keyword for the master book catalog The bookstore shall provide a secure means of allowing customers to pay by credit card The bookstore shall provide a secure means of allowing customers to pay via purchase orders Adapted from Rosenberg’s “Applying Use Case Driven Object Modeling with UML”

Sample Application (2) Initial Requirements for Internet Book Store (2) The bookstore shall provide a special kind of account that is preauthorized to pay via purchase orders The bookstore shall provide electronic links between the Web and database and the shipping fulfillment system. The bookstore shall provide electronic links between the Web and database and the inventory management system The bookstore shall maintain reviews of books, and allow anyone to upload review comments. The bookstore shall maintain ratings on books, based on customer inputs. Adapted from Rosenberg’s “Applying Use Case Driven Object Modeling with UML”

Sample Application (3) Initial Domain Model for Internet Bookstore
Adapted from Rosenberg’s “Applying Use Case Driven Object Modeling with UML”

Introduction to Use Cases (1)
More recent terminology, but long practiced technique (study operational scenarios of system) Use cases are used to describe the outwardly visible requirements of a system Used by some as a form of requirements specification Used by others as a form of high-level design Used by others as a form of requirements elicitation A use case is a sequence of actions that an actor performs within a system to achieve a particular goal

Use cases are described as an interaction (stimulus/response) Person does X System does Y Only concerned with visible behavior Customer requests a list of products System shows all available products Usually limited to those that achieve client end-goal Typical non-example: Customer logs in Called semi-manufactured use cases

Elements of a Use Case description Actor: entity interacting with the system (really a role) Humans, organizations, other systems, … Normal Flow: Normal sequence of action/reaction pairs that enable the actor to achieve the goal Alternative Flow(s): Variations in the normal sequence that are expected Exception Flow(s): Variations in the normal or alternative flows that are not expected (errors) Use cases are read by the client!!!

Requirements and Use Cases
Functional requirement: a function or a characteristic of a function, requested by the customer or by some other stakeholder of the system Use Case A way the system can be used by a user (actor) - Relationship between Requirements and Use Cases Each use case can satisfy many functional requirements A functional requirement can be related to many use cases Each use case can have many non-functional requirements associated with it Though use cases don’t represent non-functional requirements

Use Case Role Use case: Customer Order Requirements Delivery Units
Seller Customer Requirements Delivery Units Analysis & Design Models Test cases

Use Case Model (1) Includes two parts:
Use Case Diagram (usually one with all use cases) Use Case Descriptions (many, one for each use case)

Use Case Model (2) Sample Use Case Description See Use Case Template
UseCaseTemplate.doc

Relations between Use Cases (1)
Extends (shown as <<extends>>) When one use case adds behavior to another Used to model a part of a use case that the user may see as an option Also models a separate sub-case which is executed conditionally Uses (shown as <<uses>>) When one use case invokes another Used to avoid describing the same flow of events several times Puts the common behavior in use of its own

Relations between Use Cases (2)

Use Case Support

Developing Use Cases (1)
Start with requirements Must provide use case(s) for each one Find the actors Identify types of users Add system maintenance actors Find the Use Cases Describe what value the client will receive Use storyboard to help outline interactions Trace each use case to specific requirements Give brief description Name Paragraph description Requirements

Build the Use Case Diagram Represents an overview Avoid <<extends>> and <<uses>> Limit to “real” use cases (not semi-manufactured) Prioritize the Use Cases Identify types of users Add system maintenance actors

Detail the Use Cases Expand paragraph into stimulus-response Don’t assume any particular design/implementation Refer to user interface in abstract terms Choose one “normal flow” Add necessary “alternative” and “exception” flows Name the objects that are manipulated (even UI objects) Structure the Use Case Model Add the appropriate <<extends>> and <<uses>> links Create use case packages

Example Use Case Open Account (from Internet Bookstore Example)
Basic Course Alternative Courses If the customer did not provide a name, the system displays an error message to that effect and prompts the customer to type a name If the customer provided an address that is not in the correct format, the system displays an error message to that effect and prompts the customer to type a different address. … Actor System 1. The customer enters his/her name, address, and a password (twice) The system ensures that the customer has provided valid data The system creates a new account for the customer The system returns the customer to the home page of the application. 2. The customer provides additional profile information including address, phone and contact information A The system adds this information to the account

Hints (1) Don’t write functional requirements
Use cases must describe interactions Requirements say “what” Use Cases say “how” (abstractly) Don’t over focus on attributes/methods in use cases Recall that audience includes client Don’t be too terse in your initial descriptions Should be able to write a paragraph or two to start Don’t divorce completely from user interface Story boards should clearly show how actor can achieve stimulus

Hints (2) Do give user interface object names
For example, Registration Window Do write use case from the user’s perspective Use active voice Don’t ignore system responses Use case shows a dialog of observable behavior Do use story boards to follow use case flow

Use Case Review (1) Identifying Actors
All external entities that interact with the system have been identified All actors are entities outside the system Each actor is an abstraction of a specific role Each actor is the most specific delineation of the role possible Appropriate abstract actors have been identified when multiple actors share common behavior All actors derive observable value from/provide observable value to the system Adapted from Jacobson “Advanced Use Case Modeling”

Use Case Review (2) Identifying Use Cases Writing Use Cases (1)
The set of use cases covers all requirements of the system The name of each use case is a verb-noun phrase stated from the perspective of the actor The name of the use case reflects the actor’s goal in interacting with the system Writing Use Cases (1) The terminology of the description is consistent with the system glossary Each use case is complete; it provides the necessary behaviors and interactions to satisfy the actor’s goals The use case provides a description from the actor’s perspective The use case includes all necessary and appropriate alternative and exception paths Adapted from Jacobson “Advanced Use Case Modeling”

Use Case Review (3) Writing Use Cases (2)
All actors associated with the use case are entitled to all the functionality described in the use case The granularity, approach, and style used to write the use case descriptions are consistent with the other use cases Alternative flows indicate the triggers that cause deviations from the normal course. Adapted from Jacobson “Advanced Use Case Modeling”

No System (1) Adapted from Cockburn “Writing Effective Use Cases”

No System (2) Adapted from Cockburn “Writing Effective Use Cases”

No Primary Actor (1) Adapted from Cockburn “Writing Effective Use Cases”

No Primary Actor (2) Same as earlier example Adapted from Cockburn “Writing Effective Use Cases”

Too Much UI Detail (1) Adapted from Cockburn “Writing Effective Use Cases”

Too Much UI Detail (2) Adapted from Cockburn “Writing Effective Use Cases”

Very Low Level Goals (1) Adapted from Cockburn “Writing Effective Use Cases”

Very Low Level Goals (2) Adapted from Cockburn “Writing Effective Use Cases”

User Stories More software engineers are working with the Agile concept of a user story General definition: a higher-level statement, from the user’s perspective, of a process they will take or a need they have with the system Story: collection of scenarios Scenario: a collection of steps Gives up detailed system interaction for clarity

User Stories (2) Value of user stories
Can help generate/check requirements Can be used in behavior-driven development ( Can work with other tools; e.g. Cucumber Can be used to generate tests Approach State user stories in more formal yet easily read language

User Stories (3) Format Narrative In order to <do something>
As a <role> I want to <goal> Scenario (one or more) Given <precondition> When <occurrence of event> Then <outcome of event>

User Stories (4) Example (from cukes.info) Feature: Addition
In order to avoid silly mistakes As a math-challenged person I want to be told the sum of two numbers Scenario: Add two numbers Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press “add” Then the result should be 120 on the screen

Traceability Matrix (1)
What is a Traceability Matrix? Lists all user and functional requirements Lists all design specifications that address each requirement Lists all testing references which verify that the requirements have been met

Sample Traceability Matrix

Why Create a Matrix? Demonstrates that the implemented system meets the requirements Serves as a single source for tracking purposes Identifies gaps in the design and testing Prevents delays in the project timeline, which can be brought about by having to backtrack to fill the gaps

Role of Matrix in Lifecycle of Project

Requirements Engineering

Similar presentations

Presentation on theme: "Requirements Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirements Engineering

Similar presentations

Presentation on theme: "Requirements Engineering"— Presentation transcript:

Similar presentations

About project

Feedback