Business Context for Requirements

Requirements don't appear in isolation but are usually defined or discovered in the context of a business problem or opportunity that has been defined in one or more business documents. These documents and the information they contain can be included in the models and provide an important anchor point for Requirements.

Business Case

The Business Case is a high level document or argument that attempts to articulate the reasons for initiating a project. It is an important artifact for the requirements analyst because it will typically contain information describing business value, drivers and business and technical risks. It places the endeavor in the context of other functions in the business and describes the solution options at a high level. It is an important source for requirements and should be included as an artifact in the model.

Drivers and Goals

Business Drivers and Goals are often documented by high level strategic thinkers such as business or enterprise architects. Drivers define resources, processes or constraints that are vital to the operation of the organization and Goals describe the position that the organization is wanting to attain. They are typically enterprise level concerns and so should be modeled above the level of individual projects. They often exist in high level documentation and even when they aren't clearly articulated at the organization level an analyst can mine them from previous project documentation such as a Vision document and model them in an enterprise Package above the project Packages in the repository.

Vision and Concept of Operation

While the Business Case describes the business reason for initiating the project the Vision typically elaborates the opportunity or problem in more detail describing the business context, the market position, key stakeholders and requirements, solution choices and constraints. The vision is more often than not created prior to the team being assembled and can be a great source of requirements information. The required system functionality is often expressed using Features.

Enterprise Architect has a wide range of tools and element types that can be used to model the contents of the Vision Document including Users, Stakeholders, architecturally significant Use Cases and Requirements, Constraints and Deployment Environments.

Policies and Business Rules

A Policy is a high level principle or statement of intent typically defined and managed by a governance body; a Business Rule is an implementation of the Policy. They are not strictly requirements and are often defined at the enterprise level rather than the project level, which facilitates their reuse across multiple projects. Policies and Business Rules can be modeled using stereotyped Requirement elements, and business and system requirements can be traced to them from individual projects. There is some overlap with regulatory and safety requirements, which some methods consider to be types of Business Rules. Enterprise Architect supports the modeling of Polices and Business Rules using stereotyped Requirements, but also has a powerful Business Rule Modeling capability that can create executable code for a variety of languages.

Business Rule Modeling is available in the Unified and Ultimate editions of Enterprise Architect

Stakeholders and Their Concerns

Stakeholders typically have the same set of concerns regardless of whether projects are running or not. A Security Manager will for example be concerned about the vulnerability of sensitive organizational data, a Customer Experience Manager will be concerned about speed of access and a Chief Financial Officer will be interested in return on investment. These concerns can be modeled at the enterprise level as they are generic and independent of individual projects. They will provide a source of understanding for project level requirements and will help identify gaps in the requirements landscape. Enterprise Architect can be used to model Stakeholders using a stereotyped UML Class and these high level concerns can be modeled using a requirement stereotyped as a Stakeholder Concern.