Requirements Engineering

• helps software engineers better understand the problems they are trying to solve
• produce a written understanding of the customer's problem
  
  
• Requirements Engineering
  • must be adapted to the needs of a specific process, project, product, or people
    
  • begins during the software engineering communication activity and continues into the modeling activity.
  • may be abbreviated, but it is never abandoned
    
    
• Requirements Engineering Tasks
  
  
  
  
  
  
• Requirements Management
  • activities that help project team to track requirements and changes as project proceeds
  • requirements are identified, tagged with a unique identifier, and classified by type (functional, data, behavioral, interface, or output)
  • traceability tables are developed and updated any time a requirement is modified
  • use of a database can help software teams track requirement changes
    
    
• Traceability Tables
  • features traceability table - shows how requirements relate to customer observable features
  • source traceability table - identifies source of each requirement
  • dependency traceability table - indicate relations among requirements
  • subsystem traceability table - requirements categorized by subsystem
  • interface traceability table - shows requirement relations to internal and external interfaces
    
    
    
    
• Inception
  
  
  • identify stakeholders
  • recognize the existence of multiple stakeholder viewpoints
  • work toward collaboration among stakeholders
  • these questions focus on customer, stakeholders, overall goals, and benefits of the system
    • Who is behind the request for work?
    • Who will use the solution?
    • What will be the economic benefit of a successful solution?
    • Is there another source for the solution needed?
  • the next set of questions enable developer to better understand the problem and the customer's perceptions of the solution
    • How would you characterize good output from a successful solution?
    • What problem(s) will this solution address?
    • Can you describe the business environment in which the solution will be used?
    • Will special performance constraints affect the way the solution is approached?
  • the final set of questions focuses on communication effectiveness
    • Are you the best person to give "official" answers to these questions?
    • Are my questions relevant to your problem?
    • Am I asking too many questions?
    • Can anyone else provide additional information?
    • Should I be asking you anything else?
      
      
• Elicitation
  
  
  • collaborative requirements gathering
    
    
    
    
  • quality function deployment (QFD)
    • formal approach used to determine the value of each function that is required for the system
    • identifies three types of requirements (normal, expected, exciting)
    • information deployment identifies data objects and events (these are linked to functions)
    • task deployment examines the system behavior
    • value analysis determines relative priority of each requirement
      
      
  • user-scenarios
    • informal approach, also known as use-cases, describe how the system will be used
    • developers and users create a set of usage threads for the system to be constructed
    • developing use-cases
      • use-case tells a stylized story about how end-users interact with the system under a specific set of circumstances
      • first step is to identify actors (people or devices) that use the system
        • Who are the primary or secondary actors?
        • What preconditions must exist before story begins?
        • What are the main tasks or functions performed by each actor?
        • What extensions might be considered as the story is described?
        • What variations in actor interactions are possible?
        • What system information will the actor acquire, produce, or change?
        • Will the actor need to inform the system about external environment changes?
        • What information does the actor desire from the system?
        • Does the actor need to be informed about unexpected changes?
      • use-case template
        • Name
        • Primary actor
        • Goal in context
        • Preconditions
        • Trigger
        • Scenario details
        • Extensions
        • Priority
        • When available
        • Frequency of use
        • Channels to secondary actors
        • Open issues
      • use-case drawbacks
        • lack of formality in use-case descriptions
        • not all systems have explicitly defined actors
        • use-cases are not inherently object-oriented
        • developers have a tendency to functionally decompose use-cases
    • SafeHome example in text
      
      
      
      
      
      

    
    

  • elicitation work products
    
    
    
    
    
• Elaboration
  • provide descriptions of required information, functional, and behavioral domains
  • create an analysis model
    • elements of an analysis model
      • scenario-based elements - describe the system from the user's perspective
      • class-based elements - relationships among objects manipulated by actors and their attributes
      • behavioral elements - depict system and class behavior as states and transitions between states
      • flow-oriented elements - shows how information flows through the system and is transformed by the system functions
        
        
        
        
    • many different representations can be used
      • use-case diagrams
      • activity diagrams
      • class diagrams
        
        
        
      • state diagram - for a copy machine
        
        
        
      • data flow diagram (DFD)
        
        
    • UML provides many modeling tools - see Borland's UML Tutorial
      
      
• analysis pattern
  • a commonly present element in an analysis model
  • these can be reused to speed up the process
  • analysis pattern template
    
    
• Negotiation
  • negotiation activities
    • identification of key stakeholders
    • determination of stakeholders' "win conditions"
    • negotiate to reconcile stakeholders' win conditions into "win-win" result for all stakeholders (including developers)
  • key points
    • it's not a competition
    • map out a strategy
    • listen actively
    • focus on other party's interests
    • don't let it get personal
    • be creative
    • be ready to commit
      
      
• Validation
  • a formal technical review process
  • key questions
    • Is each requirement consistent with overall project or system objective?
    • Are all requirements specified at the appropriate level of abstraction?
    • Is each requirement essential to system objective or is it an add-on feature?
    • Is each requirement bounded and unambiguous?
    • Do you know the source for each requirement?
    • Do requirements conflict with one another?
    • Is the requirement achievable in the proposed technical environment for the system or product?
    • Is each requirement testable?
    • Does the requirements model reflect the information, function, and behavior of the system to be built?
    • Has the requirements model been partitioned in a way that exposes more detailed system information progressively?
    • Have all the requirements patterns been properly validated and are they consistent with customer requirements?

Notes and figures from:

• Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005