Artifacts Used in Requirements

When considering requirements, it is important, first of all, to understand the definition and scope of the problem that we are trying to solve with this system. The business object model, developed during business modeling, will serve as valuable input to this effort. Stakeholders are identified, and Stakeholder Requests are elicited, gathered, and analyzed .

Stakeholder Requests are actively elicited and gathered to get a "wish list" of what different stakeholders of the project (customers, users, product champions ) expect or desire the system to include, together with information on how each request has been considered by the project.

The key needs and features are specified in the Vision Document, and a Use-Case Model, Use Cases, and Supplementary Specifications are developed to describe what the system will do ”an effort that views all stakeholders, including customers and potential users, as important sources of information (in addition to system requirements).

The Vision Document provides a complete vision of the software system under development and supports the contract between the funding authority and the development organization. Every project needs a source for capturing the expectations among stakeholders. The Vision Document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of quality. The vision should include a description of what will be included, as well as features that were considered but not included. It should also specify operational capacities ( volumes , response times, accuracies), user profiles, and interfaces with entities outside the system boundary, where applicable . The Vision Document provides the contractual basis for the requirements visible to the stakeholders.

The Use-Case Model should serve as a communication medium and can serve as a contract among the customer, the users, and the system developers on the functionality of the system, which allows the following:

  • Customers and users can validate that the system will become what they expected.

  • System developers can build what is expected.

The Use-Case Model consists of Use Cases and Actors. Each Use-Case in the model is described in detail, showing step by step how the system interacts with the actors and what the system does in the use case. Use cases function as a unifying thread throughout the software lifecycle; the same Use-Case Model is used in system analysis, design, implementation, and testing.

The Supplementary Specifications are an important complement to the Use-Case Model, because together they capture all software requirements (functional and nonfunctional) that need to be described to serve as a complete Software Requirements Specification.

A complete definition of the software requirements, as described in the use cases and supplementary specifications, may be packaged together to define a Software Requirements Specification (SRS) for the full product, a particular "feature," or other subsystem grouping.

Complementary to the foregoing artifacts, the following artifacts are also developed:

  • A Glossary

  • Storyboards, which will serve as the basis of User-Interface Prototypes

The Glossary is important because it defines a common terminology that is used consistently across the project or organization. The glossary started in business modeling (see Chapter 8) can serve as a starting point, or simply be extended.

Current and potential users of the system should be involved in modeling and defining the user interface of the system in the Storyboards associated with Use Cases, which will serve as the basis of User-Interface Prototypes, which are developed in parallel with other requirements activities (see Chapter 10).



The Rational Unified Process. An Introduction
Blogosphere: Best of Blogs
ISBN: B0072U14D8
EAN: 2147483647
Year: 2002
Pages: 193

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