Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3

Introduction Pervading issue of how work is divided between human and computer Decided through requirements No automatic way of identifying “correct” functions in the product Some creativity is required! Requirements engineer decides on functions/screens in the product and therefore much of the future human work

Context diagrams Show the product as a black box surrounded by user groups and external systems with which it communicates Arrows show how data flow between product and surroundings (transfer of data) Excellent overview of the required product interfaces Outline context diagram early in the project and keep updated during analysis

Advantages and disadvantages Verification; context diagram gives an overview of the interfaces and serves as a high level checklist Validation; most customers can readily understand the context diagram, spot missing interfaces, discuss what is delivered and what is outside the product

Event list and function list Events to be handled by the product (or a list of product functions) Events to be handled by human + computer (or a list of user tasks) Product events are design level issues Event is something that requests a system to perform some function (usually also has data) Domain events arrive at the domain from the surroundings Product events arrive at the product from the domain

Advantages and disadvantages Developers can easily check that each event/function on the list is supported or implemented May find it difficult to check whether all events are included Many variants in each event (which can be confusing) The event list for the UI is a design issue Lists may give you a false sense of security

Feature requirements Text form; the product shall record/show/compute.. Many people believe that this is the only acceptable type of requirement Can lead to a false sense of security for user and analyst Difficult to ensure that users are adequately supported and business goals covered

Advantages and disadvantages Validation; customers love features, they use the customers language Verification; straightforward to check that all the features are implemented in the final product (but time consuming) Easy to dream up too many features Hard to understand how that meet the business goals

Screens and prototypes Screen features and what the “buttons” do Excellent as design-level requirements if carefully tested Not suited for COTS based systems

A good user interface Careful analysis of the tasks to be supported Early prototypes, preferably as mockups Usability tests to see that the prototype actually allows typical users to perform all the tasks w/o assistance Several revisions of the prototype and new tests

Advantages and disadvantages Validation; customer can ensure that the screens are able to support the tasks and provide high usability Verification; straightforward to verify that the final user interface is an specified Don’t use this approach for COTS product Tasks must be well defined

Task descriptions Structured text describing user tasks Easy to understand for user as well as developer Easy to specify variants and complexity Simple to verify Domain level requirements, also suited for COTS

Task descriptions Task; what user and product do together to achieve some goal Use case; mostly the products part of the task Human task; user’s part of the task

Advantages Validation; customers find it easy to validate the task descriptions Trace to development; easy to see a screen supports a specific task Verification; checking the final system against the task descriptions Suitable for COTS Can specify complexity

Disadvantages No data specified Non-task activities Design is harder

Features from task descriptions Product features explained by means of task descriptions Improves understanding and validation of the features You can rarely guess user tasks from the features

Tasks and support Structured text describing tasks, domain problems, and possible support for them Identifies critical issues Discusses product features in a structured way Easy to understand for user as well as developer Easy specification of variants and complexity Simple to verify Domain level requirements

Advantages Easy to understand what customer really needs Possible to trace between requirements and business goals Supplier can specify advantages of solution by relating it to user tasks Supplier can also show where solution exceeds the customers expectations

Disadvantages No data specified, non-task activities More work for the supplier More work for the consumer Unusual reply format

Scenarios A case study illustrating one or more user tasks or a specific case to be tested Improves developer intuition Not requirements

Good tasks Closed task = meaningful user goal Check that you have identified all tasks Bundle small related tasks Don’t program the user dialog

High level tasks Total business cases as seen by the clients Independent of existing user tasks Idea generating – business process re- engineering (BPR) Rarely used as requirements