2 Understand Requirements

• Functional Requirements- What the system should do

  • The primary way that a customer communicates their requirements to the project team.
  • Help to keep project team going in the right direction
  • Example- The system must send a confirmation email whenever an order is placed.
  • Example- The system must allow users to verify their accounts using their phone numbers, business rules, administrative functions,
• Requirements Engineering: Inception

  • Establish a basic understanding of the problem, the people who want a solution, and the nature of the solution desired
  • Important to establish effective customer and developer communication
• Requirements Engineering: Elicitation

  • Elicit requirements and business goals from all stakeholders
• Requirements Engineering: Elaboration

  • Focuses on developing a refined requirements model that identifies aspects of software function, behavior, and information
• Requirements Engineering: Negotiation

  • Agree on the scope of a deliverable system that is realistic for developers and customers
• Requirements Engineering: Specification

  • Can be any or all of the following: written documents, graphical models, mathematical models, usage scenarios, prototypes
• Requirements Engineering: Validation

  • Work products produced during requirements engineering are assessed for quality and consistency
• Requirements Engineering: Requirements management

  • Set of traceability activities to help the project team identify, control, and track requirements and their changes to requirements as the project proceeds
• Establishing the Groundwork

  1. Identify stakeholders: “who else do you think I should talk to?"
  2. Recognize multiple points of view.
  3. Work toward collaboration
  4. The first questions: Who is behind the request for this work?, Who will use the solution?, What will be the economic benefit of a successful solution?
  5. Non-functional Requirements(NFR) – quality attribute, performance attribute, security attribute, or general system constraint
  6. Traceability A SE term refers to documented links between SE work products (e.g. between requirements and the test cases).
• Requirements Gathering: Collaborative

  • Meetings (real or virtual) are conducted and attended by both software engineers and other stakeholders.
  • Rules for preparation and participation are established
  • Agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas
  • A “facilitator” (customer, developer, or outsider) controls the meeting
  • A “definition mechanism” (worksheets, flip charts, wall stickers, or virtual forum) is used.
  • Goal is to identify the problem, propose solution elements, and negotiate different approaches.
• Requirements Gathering: Elicitation Work Products

  • Statement of need and feasibility
  • Bounded statement of scope for the system or product
  • List of customers, users, and other stakeholders who participated in requirements elicitation
  • Description of the system’s technical environment
  • List of requirements (preferably organized by function) and the domain constraints apply to each
  • Set of usage scenarios (written in stakeholders’ own words) that provide insight into the use of the system or product under different operating conditions.
• Requirements Gathering: Usage Scenarios

  • Informal descriptions of the system that provide a high-level description of system operations, classes of users, and exceptional situations
  • Useful when the domain is novel. User stories are a form of scenario
• Requirements Gathering: User Stories

  • Are similar to scenarios except that they are written by the customers in terms of what the system needs to do for them
• Requirements Gathering: Focus Groups

  • The most celebrated group-oriented work for requirements discovery is Joint Application Design (JAD)
• Requirements Gathering: Interviews

  • Opposite of group activities, a one to one interview
• Requirements Gathering: Brainstroming

  • Informal sessions with Stakeholders to generating overarching goals for the system.
• Requirements Gathering: Card Sorting

  • Stakeholders complete a set of cards that includes key information about functionality for the system/software product
• Requirements Gathering: Prototyping

  • This involves constructing a model of the system that are either working or non-working.
• Use Case Definition

  • A collection of user scenarios that describe the thread of usage of a system
  • Each scenario is described from the point-of-view of an actor - a person or device that interacts with the software in some way
  • Each scenario answers the following questions: Who is the primary actor, the secondary actor (s)?, What are the actor’s goals?, What preconditions should exist before the story begins ?
• Analysis Model Elements

  • Analysis model provides a description of the required informational, functional, and behavioral domains for a computer-based system.
  • Scenario-based elements – functional descriptions are express in the customers own words and user stories and as interactions of actors with the system expressed using UML use case diagrams
  • Class-based elements – collections of attributes and behaviors implied by the user stories and expressed using UML class diagrams (information domain)
  • Behavioral elements – may be expressed using UML state diagrams as inputs causing state changes.
• Negotiating Requirements

  • strive for a “win-win” result, stakeholders win by getting a product satisfying most of their needs and developers win by getting achievable deadlines
  • Handshaking is one way to achieve a “win-win"
  • Developers propose solutions to requirements, describe their impact, and communicate their intentions to the customers
  • Customer reviews the proposed solutions, focusing on missing features and seeking clarification of novel requirements
  • Requirements are determined to be good enough if the customers accept the proposed solutions
• Requirements Monitoring

  Useful for incremental development include:

  1. Distributed debugging - uncovers errors and determines their cause.
  2. Run-time verification - determines whether software matches its specification
  3. Run-time validation - assesses whether the evolving software meets user goals
  4. Business activity monitoring - evaluates whether a system satisfies business goals
  5. Evolution and codesign - provides information to stakeholders as the system evolves.
• Non-Functional Requirements- How the system preforms a function

  • Describes how a system should behave and what limits there are on its functionality
  • Examples- Scalability, Capacity, Availability, Reliability, Recoverability, Maintainability, Serviceability, Security, Regulator
• Validating Requirements

  • Is each requirement consistent with the overall objective for the system/product?
  • Do any requirements conflict with other requirements?
  • Is each requirement achievable in the technical environment that will house the system or product?
  • Does the requirements model properly reflect the information, function and behavior of the system to be built?
• Requirements Engineering Order

  1. Inception
  2. Elicitation
  3. Elaboration
  4. Negotiation
  5. Specification
  6. Validation
  7. Requirements Management