|
More accurate requirements and a more useful application are achieved by defining detailed requirements based on the way users and external systems will use the application currently being developed. Use the links below for an overview of the activities. For details about a role, activity, or artifact in the diagram, click on its icon.
More detail: Purpose - How to Staff
|
|
| Purpose |
|
The purpose of this workflow detail is to:
- Iteratively define the required interactions between the actors (roles played by users and external systems) and the application or website under development
- Identify and manage dependencies and relationships among various requirements
- Gain key stakeholders' approval of the requirements
To define functional requirements, the Role: Requirements Analyst facilitates working sessions with Role: Subject Matter Experts. These sessions specify the flow of events in each Artifact: Use Case. A use case may be documented textually or graphically with activity diagrams. People in the Requirements Analyst, Subject Matter Expert, and Information Architect roles collaborate to refine the use cases based on the experts' business knowledge, the Information Architect's user interface models, and the Requirements Analysts continuing investigation of requirements and their relationships.
The use cases typically serve as the anchor point for feature and functional definition, with all supporting artifacts synchronized accordingly. Change, however, will be bi-directional: a desired function may be identified through the Artifact: Site Map or Artifact: Wireframes, and this will need to be reflected in the corresponding use cases. Throughout this work, the Requirements Analyst updates the Artifact: Use Case Model to reflect refined actors, use case names, and use case relationships.
Traceability and requirements dependencies are defined during use case development. The detailed requirements in the use cases may trace back to elements in the Artifact: Business Concept and the Artifact: Marketing Plan.
Through close collaboration among roles and the use of a controlled set of complementary artifacts, the team specifies the functional requirements and information architecture in an optimal fashion. (For projects with limited functionality, use case specifications may become secondary to the information architecture for documenting functional requirements.) By iteratively developing the use cases and reviewing requirements with people acting as Role: Requirements Reviewers, the team establishes baselines for detailed requirements.
|
| How to Staff |
|
The number of use cases, their complexity, and time constraints will influence the number of people needed for the Role: Requirements Analyst. If several people fulfill this role, a single person should be designated as the Lead Requirements Analyst to coordinate efforts.
People filling other roles on the project typically also act as the Role: Requirements Reviewer. For example, Subject Matter Experts, Testers, Software Architects, Software Designers, Information Architects, Usability Evaluators, and other stakeholders may be Requirements Reviewers at different points in the project. Conducting frequent informal reviews, especially to improve quality before reviewing the use cases with Software Designers and Stakeholders, speeds more formal reviews and allows those reviewers to focus on the requirements instead of problems like inconsistent vocabulary, incorrectly formatted steps, ambiguous statements, inconsistency between use cases, etc.
The Requirements Analyst, Subject Matter Experts, Information Architects, and others form a multi-disciplinary team (sometimes referred to as a requirements team) to elicit requirements used as the basis for software development. Each role has a different view of the requirements and users' needs. All of these views need to be taken into consideration to create a suitable and interesting system. It is important that those fulfilling these roles respect each competency's contributions to the project.
|
|
|
Workflow