Section 9. Functional and Data Requirements


9. Functional and Data Requirements

9a. Functional Requirements

Content

A specification for each functional requirement. As with all types of requirements, use the requirements shell. A full explanation is included in this template's introductory material.

Motivation

To specify the detailed functional requirements for the activity of the product.

Examples

See Figure B.4 for an example of a filled in snow card.

Figure B.4. A sample of a functional requirement using a snow card. Usually these requirements would be recorded in some electronic form using only textual field identifiers.


Fit Criterion

Each functional requirement should have a fit criterion or a test case. In any event, the fit criterion is the benchmark to allow the tester to determine whether the implemented product has met the requirement.

Considerations

If you have produced an event/use case list (see sections 7b and 8a), then you can use it to help you trigger the functional requirements for each event/use case. If you have not produced an event/use case list, give each functional requirement a unique number and, to help with traceability, partition these requirements into event/use case-related groups later in the development process.

9b. Data Requirements

Content

A specification of the essential subject matter, business objects, entities, and classes that are germane to the product. It might take the form of a first-cut class model, an object model, or a domain model. Alternatively, these requirements might be described by defining the terms in the dictionary described in section 5.

Motivation

To clarify the system's subject matter, thereby triggering recognition of requirements not yet considered.

Example

Figure B.5 is a model of the system's business subject matter using the Unified Modeling Language (UML) class model notation.

Figure B.5. The class model showing the stored data requirements.


You can use any type of data or object model to capture this knowledge. The issue is to capture the meaning of the business subject matter and the connections between the individual parts, and to show that you are consistent within your project. If you have an established company standard notation, use that, as it will help you to reuse knowledge between projects.

Considerations

Are there any data or object models for similar or overlapping systems that might be a useful starting point? Is there a domain model for the subject matter dealt with by this system?




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net