|
The purpose of this workflow detail is to:
- Identify the boundaries of the system, website, or web-based application by creating or refining the Artifact: Use Case Model and Artifact: Actor Catalog
- Identify the functionality and the quality attributes the application should possess by outlining the Use Cases and refining the Artifact: Supplementary Specification
- Gain agreement from all stakeholders, including the project team, regarding the scope
- Determine priorities for detailing functionality and building the application
The results from activities such as Activity: Develop Business Concept and Activity: Research Potential User Needs are the primary inputs to defining the application's functionality and scope. The Role: Requirements Analyst investigates beyond these activity results to determine the external system interfaces and the system-wide attributes. This may build upon information gathered during the Activity: Perform Enterprise Analysis and Activity: Understand Technical Infrastructure.
If the team developed the Artifact: Business Use Cases then defining the relationship between the Business Use Cases and the (system or application) Artifact: Use Cases is beneficial. A Use Case may fully or partially support one or more Business Use Cases. Some Business Use Cases may not have any application support. Clearly showing the relationship between the application and the business processes provides context and ensures that the application is supporting business needs.
Establish a baseline for the application scope by the end of the Inception phase. This provides the foundation on which to base estimates and plans. Control scope baseline changes with the approach defined in Activity: Establish Change Control Process.
|
|
Whether an individual or a team, the Role: Requirements Analyst works closely with stakeholders, Role: User Researcher, and (ideally) users to elicit user needs. The Role: Business Strategist contributes by ensuring that the features and attributes identified as part of the Artifact: Business Concept are included. The Role: Information Architect may participate in workshops, interviews or other situations where requirements are discussed because they need to understand this information in order create effective user interfaces.
The Role: Software Architect participates in these discussions to better understand the goals of the application, the domain, and potential risks. Further, the person acting as the Software Architect should have experience estimating effort, identifying risks, and setting priorities. Those characteristics make iterative development successful.
|