Requirements - Creation

Software Engineering
1.0x

Requirements - Creation

Created 3 years ago

Duration 0:04:17
lesson view count 466
Select the file type you wish to download
Slide Content
  1. Requirements: Creation

    Slide 1 - Requirements: Creation

    • Emerson Murphy-Hill
  2. Requirements Elicitation

    Slide 2 - Requirements Elicitation

    • Need to understand why not just what.
    • Techniques
    • Interviews
    • Observation
    • Examining Documents and Artifacts
    • Joint Application Design (JAD)
    • Groupware
    • Questionnaires
    • Prototypes
    • Focus Groups
    • On-Site Customer
    • Existing System
  3. Requirements Validation

    Slide 3 - Requirements Validation

    • Critical step in the development process,
    • Usually after requirements engineering or requirements analysis. Also at delivery
    • Requirements validation criteria:
    • Correctness:
    • The requirements represent the client’s view.
    • Completeness:
    • All possible scenarios through the system are described, including exceptional behavior by the user or the system
    • Consistency:
    • There are no requirements that contradict each other
    • Clarity:
    • There are no ambiguities in the requirements.
    • Concision
  4. Requirements Validation Criteria (continued)

    Slide 4 - Requirements Validation Criteria (continued)

    • Feasible:
    • Requirements can be implemented and delivered
    • Traceability:
    • Each system function can be traced to a corresponding set of functional requirements
    • Understandable
    • Non-prescriptive
    • everything about what the customer wants and nothing about how the programmer(s) will do it.
    • Consistent language
    • Shall, should, may
    • “the physician” vs. “the doctor”
    • Testable
  5. Types of Requirements Statements

    Slide 5 - Types of Requirements Statements

    • Traditional
    • “The system shall”
    • Use case based (a.k.a. iTrust)
    • User story – married with acceptance test to supply the detail
    • Agile requirements
  6. Traditional Requirements Statements

    Slide 6 - Traditional Requirements Statements

    • Shall (== is required to): used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted
    • Should (== is recommended that): used to indicate
    • among several possibilities one is recommended as particularly suitable, without mentioning or excluding others
    • or that a certain course of action is preferred but not necessarily required;
    • or that (in the negative form) a certain course of action is deprecated but not prohibited
    • May (== is permitted to): used to indicate a course of action permissible within the limits of the standard
    • Can (== is able to): used for statements of possibility and capability, whether material, physical, or causal
    • http://standards.ieee.org/guides/style/section5.html
  7. Example Traditional Requirements

    Slide 7 - Example Traditional Requirements

    • From course pack …
    • There shall be two dice in the game. Each dice shall have six faces. The player’s movement shall be based on the dice roll. If the dice roll is two, the player shall move forward two cells; if the dice roll is three, the player shall move forward three cells; etc.
    • If a player is sent to jail by either landing on the Go to Jail cell or drawing a go to jail card, the player shall pay $50 in bail money to get out of jail at their next turn. If a player lands on jail as the result of a dice roll, nothing shall happen.