Requirements Engineering and Management INFO 627 Refining the System Definition Glenn Booker INFO 627 Lecture #6

Requirements Now that we have a good idea of the customer needs, have defined the main features for our system, and selected a structure for managing the implementation of those features… *whew* We can now work on refining requirements to guide development and testing INFO 627 Lecture #6

Requirements As we define and refine requirements, it must be clear that the written description of those requirements is the only authority as to what we are creating And changes in scope or intent need to be reflected immediately We started by defining features vaguely – now we add details INFO 627 Lecture #6

Requirements The system must fulfill user needs The system requirements must be complete and consistent, and fit in the environment where it will live Definition of requirements also supports detailed feasibility study, to ensure we are making a wise investment INFO 627 Lecture #6

Requirements How precise requirements need to be depends on the type of application and the industry it supports We hope that aircraft flight control software is designed more carefully than Microsoft Word Goal is to produce understandable requirements to support meeting user needs INFO 627 Lecture #6

Requirements Many methods or models can be used to express requirements Use Cases Natural language Formal methods (Z or Larch) Storage and management of those requirements could be in a spreadsheet or database INFO 627 Lecture #6

Requirements Requirements need to be: Understood by all parties concerned Specific enough to be verified and demonstrated From the beginning, think of requirements in terms of being able to prove whether they have been fulfilled (“Trust but verify”) INFO 627 Lecture #6

Software Requirements Software requirements are generally related to some capability the user needs to have, or some capability the systems needs for some other reason Inputs and outputs are good places to start looking for requirements Don’t forget non-functional requirements! INFO 627 Lecture #6

Software Requirements Think of the system as a black box, and focus on what needs to go into and leave the system Five major classes of things can describe a system (per Davis) Inputs to the system, in terms of content, format, and source INFO 627 Lecture #6

Software Requirements Outputs from the system, including the type of output device, and format of the outputs Functions of the system, to accept inputs and/or create outputs Attributes of the system, such as the “–ilities”, throughput, and performance Attributes of the system environment, such as where it is used, and compatibility with other systems INFO 627 Lecture #6

Software Requirements Using this kind of breakdown helps ensure completeness of requirements Also can use these categories to help determine if something really is a requirement Features lead to one or more requirements So requirements help to define the scope and exact capabilities of features INFO 627 Lecture #6

Mapping Features to Requirements 1E p. 231 We need to trace the origin of requirements from their corresponding features This traceability helps ensure we define complete requirements All features result in one or more requirements [Side note: Microsoft products don’t recognize “traceability” as a word…does that tell us something about their products?] INFO 627 Lecture #6

What Requirements Are Not The challenge in writing requirements is to avoid things which shouldn’t impersonate requirements Project management information Unneeded design or implementation details Testing information Requirements should focus on system behavior, not its inner workings INFO 627 Lecture #6

Project Management Information Requirements should not include Budget, staffing, or schedule information Configuration management plans Testing plans (except maybe hints for very unusual cases) Put these in separate Program Management Plan, CM Plan, etc. INFO 627 Lecture #6

Unneeded Design Details Do not define the system design or architecture as requirements Reduces the creativity of the developers to use an even better approach Includes specifying development language, tools, design methodology (e.g. OO vs. relational database) INFO 627 Lecture #6

Design Constraints If an aspect of the system design is artificially constrained BY THE CUSTOMER, make it a design constraint Only if the customer mandated it Other design decisions should only appear in design documents, not hiding among requirements E.g. if using VB is the best language INFO 627 Lecture #6

Testing Plans Requirements do not include Test plans Verification and validation plans Test cases In very rare cases, a testing approach may be hinted at or suggested if a suitable approach may not be obvious INFO 627 Lecture #6

Implied Requirement Details Beware of stating assumptions about the form or format of an input or output E.g. an output might be assumed to be on paper, but why not a web page or PDF file? Be clear what assumptions are made about the environment the user will have Don’t necessarily have a keyboard and mouse INFO 627 Lecture #6

Requirements vs. Design Requirements (what the system does) should be determined before design Requirements are determined by the users and customers, since they (generally) know their needs best Design (how) is done by technical experts, because they know the options available INFO 627 Lecture #6

Requirements vs. Design Yet trying to implement requirements may lead to a design which alters the req’ts Hence in reality, design and requirements are iterative, feeding off each other until an acceptable balance is achieved Changes in technology can drastically affect requirements (client/server vs. web) INFO 627 Lecture #6

Types of Requirements A basic breakdown of requirements may include: 1E p. 237 A basic breakdown of requirements may include: Functional software requirements Non-functional software requirements Design constraints Functional requirements focus on actions (user does x, system does y) See also lecture 2, INFO 620 for the FURPS+ model INFO 627 Lecture #6

Non-Functional Requirements Non-functional requirements typically include: Usability Time needed for training Time to perform task Usability compared to other systems Availability of help Compliance with HCI standards (Windows, Mac) INFO 627 Lecture #6

Non-Functional Requirements Reliability Availability (%) Mean time between failures (MTBF, hours) Mean time to repair (MTTR, hours) Accuracy (numeric precision, number of decimals) Defect rate (defects/1000 lines of code) Bugs per type (number of bugs by severity) INFO 627 Lecture #6

Non-Functional Requirements Performance Response time for a transaction – average, maximum, some % below some value Throughput (transactions per second) Capacity (number of simultaneous users) Degraded modes of operation (what are performance expectations if system is partially offline) INFO 627 Lecture #6

Non-Functional Requirements Supportability Expected implementation time for minor, medium, and major enhancements Planned or possible future enhancements mostly affect design decisions INFO 627 Lecture #6

Design Constraints We generally want to define requirements so that several design approaches might be used to implement them Constraints might need to be imposed such as the development language, use of corporate reuse libraries, coding standards, or external standards such as FDA, DOD or FCC regulations INFO 627 Lecture #6

Design Constraints Should distinguish constraints from requirements, such as using a “DC” prefix, and isolate them from the true requirements Identify the source of each constraint, and why it was imposed (if known) INFO 627 Lecture #6

Parent-Child Requirements A child requirement specifies details about its parent Could look on as the parent is a requirement, and the child a specification Don’t go crazy with lots of grandchildren and great-grandchildren – usually not worth the effort INFO 627 Lecture #6

Use Case Refinement Use cases make sense particularly when a system has lots of functions to perform, and you’re using an OO methodology If there are few users or interfaces, or extensive non-functional requirements, might not be the best choice INFO 627 Lecture #6

Use Case Refinement Use cases focus on who does something (actor), how they interact with the system, and what the system does in response (including tasks like saving data, displaying a report, etc.) Use case must be of value to the actor Name each use case clearly and concisely INFO 627 Lecture #6

Use Case Refinement Refinement of use cases may include: The basic flow, or main success scenario Variants or alternative flows – such as different methods of payment, processing personal versus business orders, or error conditions Preconditions – what happens before this use case may be used? Postconditions – what has changed as a result of this use case? INFO 627 Lecture #6

Software Requirements Specification (SRS) A Software Requirements Specification (SRS) defines the conceptual model of what the system will be Main standard is IEEE 830:1998 SRS isn’t always a single document, but a collection of documents and models Is a living package; evolves with the system INFO 627 Lecture #6

SRS Purpose The SRS serves to communicate among the developers and various stakeholders Represents an agreed contract as to what will and won’t be in the system Provides a basis for tracking completion of the system Feeds design, testing, training, etc. INFO 627 Lecture #6

SRS Ownership The SRS is owned by the developers Often each part may have a separate owner who is responsible for that part All are overseen by the Vision champion, chief architect, and the program manager INFO 627 Lecture #6

SRS Format There are many ways to arrange the contents of an SRS Text provides one structure (1E pp. 266-267), which assumes you are using use cases IEEE 830 provides another (p. 11 therein), which is more generalized Not all sections apply to every system; use “Not Applicable” if that’s the case INFO 627 Lecture #6

SRS Contents Some parts of the SRS look like Vision contents – purpose, scope, constraints, interfaces, documentation and help – but here the latter are described in more detail Other issues are now addressed – licensing and legal issues, purchased components (implying some design concept), and all requirements are identified (not just key) INFO 627 Lecture #6

SRS Contents The main body of the SRS is a detailed description of the functional and non-functional requirements Functional requirements can be broken down many ways INFO 627 Lecture #6

Functional Requirements Functional requirements may be organized (IEEE 830, App. A) by: Mode of operation of the system; best used for software-intensive mechanical systems, each mode’s functional requirements are detailed (scanning mode, editing mode, acquisition mode, etc.) If needed, each mode’s interfaces, functional, and performance requirements can be addressed INFO 627 Lecture #6

Functional Requirements User class; where each type of user of the system has well defined activities they must perform, then their functional requirements are listed Class; for object oriented systems; each class is described in terms of its attributes, methods, and messages INFO 627 Lecture #6

Functional Requirements Feature; similar to use case descriptions, identify when and how each feature is to be used, and the functional requirements for each feature Stimulus; useful when the system’s responses (functional requirements) are based on what kind of specific stimulus or message it receives INFO 627 Lecture #6

Functional Requirements Functional hierarchy; break the requirements down by information flow, process, or data construct, and provide a data dictionary to specify each data element’s format; good for reengineering legacy information systems Or any combination of the above methods (multiple organizations), such as mixing user class then stimulus and response INFO 627 Lecture #6

Non-Functional Requirements Non-functional requirements can be documented according to the structure already outlined Usability Reliability Performance Supportability INFO 627 Lecture #6

Balancing Requirements We need to review requirements for Consistent level of detail throughout the system Adequate level of detail to guide implementation, without over constraining that implementation Most of the SRS is text; graphics can be helpful but beware of adding implied design INFO 627 Lecture #6