System Definition Document / Business Requirements Specification (BRS)
Sometimes known as the User Requirements Document or Concept of Operations (ConOps) or Vision and Scope Document
A predecessor to the SRS
Sometimes known as the User Requirements Document or Concept of Operations (ConOps) or Vision and Scope Document
A predecessor to the SRS
This is a document for users, while the SRS is for developers. It should not be overly technical or formal. It may be written by a business analyst, the user (a domain expert), the developer, or a combination (maybe with help of RE consultants).
The Business Requirements Specification (BRS) describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholder perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner. In a business environment, the BRS describes how the organization is pursuing new business or changing the current business in order to fit a new business environment, and how to utilize the system as a means to contribute to the business. The description includes, at the organization level, the organizational environment, goals and objectives, the business model, and the information environment, and, at the business operation level, the business operation model, business operation modes, business operational quality, organizational formation and concept of the proposed system. It is very important that the business management level should actively participate or lead the development of the business requirement specification.
The information elements of the BRS should be specified by the business. Business management should be responsible for the content of the specification. The BRS serves as the basis of the stakeholders' active participation in the requirement processes. For example, a business analyst or representative user from the business can review the BRS and discuss the business model or operation, business management can revise the BRS, or a system analyst can review the BRS and discuss potential technical solutions. Typical types of requirements included in the BRS are organizational requirements and business requirements.
29148-2018 8.2.1
As it relates to Standard 29148-2018, this should follow 9.3 Business requirement specification (BRS). This document is sometime created instead of, and sometimes created in addition to, the 9.4 Stakeholder requirements specification (StRS), 9.5 System requirements specification (SyRS), and Annex B Concept of operations (ConOps). 29148 notes that the StRS is often identified with the business requirement specification (BRS) in many industries. Users of this document can combine the StRS with the BRS according to the users’ environment.
As it relates to SWEBOK, this is the System Definition Document (SDD).
From SWEBOK Ch. 1 Section 5.1
System Definition Document
This document (sometimes known as the user requirements document or concept of operations document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, as well as workflows.
From IEEE Std 1362-1998
Definition: A Concept of Operations (CONOPS) is a user-oriented document that "describes systems characteristics for a proposed system from a user's perspective. A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative system characteristics to stakeholders."
It should not be overly technical or formal. The user, developer, or both may write CONOPS. The main objective of a CONOPS is to "communicate with the end user of the system during the early specification stages to assure the operational needs are clearly understood and incorporated into the design decisions for later inclusion in the system and segment specifications."
From Software Requirements textbook
Some organizations create a project charter (Wiegers 2007) or a business case document that serves a similar purpose. Organizations that build commercial software often create a market (or marketing) requirements document (MRD). An MRD might go into more detail about the target market segments and the issues that pertain to commercial success.
Useful and interesting information about software engineer vs. business analyst
29148-2018 Sections 7, 8, 9 and Annex B
15288:2015 6.4.2 Stakeholder needs and requirements definition process
MITRE Systems Engineering Guide: Concept Development including Operational Needs Assessment, Concept of Operations, Operational Requirements, and High-Level Conceptual Definition - pages 275-300. VERY USEFUL. READ! Especially Best Practices
Eliciting, Collecting, and Developing Requirements - pages 304-313
Stakeholder Needs and Requirements sebokwiki
Software Requirements Engineering by Richard H. Thayer and Merlin Dorfman Details Access Chapter 1 sections III and IV pages 12-19 (PDF pages 9-18)
Concept of operations wikipedia
Concept of Operations (ConOps) (PDF). Department of Health & Human Services
Multiple CONOPS guidelines, models, and methodologies are available that can be tailored as needed for particular environments or situations. See their basic outline and description.
Example from Lockheed Martin (PDF)
Vision and Scope Document for Cafeteria Ordering System (in Wiegers book downloads)
NASA Systems Engineering Handbook - Appendix S: Concept of Operations Annotated Outline
EuTravel Stakeholder Requirements Specification - EuTravel Project
https://www.ifi.uzh.ch/dam/jcr:05621b9a-b077-4849-951d-677829401ce6/RE_I_Slides_Part_II_(5-7).pdf
1. Introduction
1.1 Business purpose - Describe at the organization level the reason and background for which the organization is pursuing new business or changing the current business in order to fit a new management environment. In this context it should describe how the proposed system will contribute to meeting business objectives.
1.2 Business scope - Define the business domain under consideration by:
a) identifying the business domain by name;
b) defining the range of business activities included in the business domain concerned. The scope can be defined in terms of divisions in the organization and external entities that relate directly to the business activities, or functions to be performed by the business activities. It is helpful to show environmental entities that are outside of the scope;
IBISWorld may be helpful with trusted industry research to help companies and institutions of all sizes make better business decisions, fast. You should auto-login when signed in to FGCU.
c) describing the scope of the system being developed or changed. The description includes assumptions on which business activities are supported by the system.
1.3 Business overview
Describe major internal divisions and external entities of the business domain concerned and how they are interrelated. A diagrammatic description is recommended.
1.4 Definitions
1.5 Major stakeholders
List the stakeholders or the classes of stakeholders and describe how they will influence the organization and business, or will be related to the development and operation of the system.
A stakeholders is an "Individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations" (ISO/IEC/IEEE 2015).
From SWEBOK: Typical examples of software stakeholders include (but are not restricted to) the following:
Users: This group comprises those who will operate the software. It is often a heterogeneous group involving people with different roles and requirements.
Customers: This group comprises those who have commissioned the software or who represent the software’s target market.
Market analysts: A mass-market product will not have a commissioning customer, so marketing people are often needed to establish what the market needs and to act as proxy customers.
Regulators: Many application domains, such as banking and public transport, are regulated. Software in these domains must comply with the requirements of the regulatory authorities.
Software engineers: These individuals have a legitimate interest in profiting from developing the software by, for example, reusing components in or from other products. If, in this scenario, a customer of a particular product has specific requirements that compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer. Specific requirements, particularly constraints, may have major impact on project cost or delivery because they either fit well or poorly with the skill set of the engineers. Important tradeoffs among such requirements should be identified.
Include an Org Chart.
2. References - Include the following information regarding references:
Provide a complete list of all documents referenced elsewhere;
Identify each document by title, report number (if applicable), date and publishing organization;
Specify the sources from which the references can be obtained.
This information may be provided by reference to an appendix or to another document. The references information should be subdivided into a 'Compliance' section, containing references to those cited documents containing requirements which are included by that citation and a ‘Guidance' section, containing reference to those cited documents containing information, but no requirements.
3. Business management requirements
3.1 Business environment - Define external and internal environmental factors that should be taken into consideration in understanding the new or existing business and eliciting the stakeholder requirements for the system to be developed or changed. The environmental factors should include possible influences to the business and consequently the system from external conditions like market trends, laws and regulations, social responsibilities and technology base.
3.2 Mission, goals, and objectives - Describe the business results to be obtained through or by the proposed system.
3.3 Business model - Describe methods by which the business mission is expected to be achieved. The description should be concentrated on the methods supported by the system to be developed or changed with the items such as product and services, geographies and locales, distribution channels, business alliance and partnership, and finance and revenue model.
3.4 Information environment - Describe the overall strategy for the organization level decisions on common bases for multiple information systems. It should include the following items.
a) project portfolio – when multiple system projects are running or planned to pursue the same business goal, the priority, relative positioning and possible constraints come from the portfolio management strategy.
b) long term system plan – when common system infrastructure or architecture has been decided or planned, it should be described as constraints on possible design decisions.
c) database configuration – an organization level database configuration plan and possible constraints on availability and accessibility of organization global data should be specified.
Where is key business information stored? How is it stored and accessed? Who is responsible for the information?
4. Business operational requirements
4.1 Business processes - Provide description of the procedures of business activities and possible system interfaces within the processes. The purpose of this information item is to represent how and in which context the system supports the business activities. In general, business processes make an ordered structure with decomposition and classification. Each business process should be uniquely named and numbered in the structure. The description of the individual business process should be represented as a diagram representing a sequence of activities
4.2 Business operational policies and rules - Describe logical propositions applied in conducting the business processes. The propositions may be conditions to start, branch and terminate the sequence of the business activities in the business processes; criteria for judgment in the business processes; or formula to evaluate a quantity, which will likely be addressed in functional requirements in the SyRS and SRS. The policies and rules shall be uniquely named and numbered, and shall be referenced in the description of the business processes.
4.3 Business operational constraints - Describe conditions to be imposed in conducting the business process. The conditions may be on a performance constraint (e.g., the process shall be finished within a day after the triggering event occurs), or may be from a management requisite such as 'every occurrence of the process shall be monitored and recorded'.
4.4 Business operational modes - Describe methods to conduct the business operation in an unsteady state, for example, a state when business operations might be extremely busy due to some intensive occurrence of events. An unsteady state of business operation includes a manual operation mode when the proposed system is not available due to some unexpected situation like an accident or natural disaster.
4.5 Business operational quality - Define the level of quality required for the business operation. For example, a business process may address required urgency with higher priority than the reliability of the business process.
4.6 Business structure - Identify and describe the structures in the business relevant to the system, such as organizational structure (divisions and departments), role and responsibility structures, geographic structures and resource sharing structures. There may be a need to align the system functions to these structures and to support future structural changes.
5. Preliminary operational concept of proposed system
5.1 Preliminary operational concept - Describe the proposed system in a high-level manner, indicating the operational features that are to be provided without specifying design details. The following information should be included:
a) operational policies and constraints;
b) description of the proposed system;
c) modes of system operation;
d) user classes and other involved personnel; and
e) support environment.
5.2 Preliminary operational scenarios - Describe examples of how users/operators/maintainers will interact with the system in important contexts of use. The high-level scenarios are described for an activity or a series of activities of business processes supported by the system. The scenarios should be uniquely named and numbered and should be referenced in the description of the business processes in 9.3.9.
6. Other preliminary life-cycle concepts
6.1 Preliminary acquisition concept - describes the way the system solution will be acquired including aspects such as stakeholder engagement, source of the solution, requirements definition, solicitation and contracting issues, design, production and verification.
Basically, what are you going to do to figure out the proper solution? At this stage, you should have an idea for a solution, the preliminary operational concept, but you should recognize that a lot more needs to be done before time, money, and effort goes into actually creating the solution. You need to meet with more people, do observations, conduct interviews, evaluate feasibility, consider design and production, etc.
6.2 Preliminary deployment concept - describes the way the system solution will be validated, delivered and introduced into operations.
6.3 Preliminary support concept - describes the desired support infrastructure and manpower considerations for supporting the system solution after it is deployed. A support concept addresses operating support, engineering support, maintenance support, supply support and training support.
6.4 Preliminary retirement concept - describes the way the system will be removed from operation and retired, including the disposal of any hazardous materials used in or resulting from the process.
7. Project Constraints
Describe constraints to performing the project within cost and schedule.
8. Appendix
8.1 Acronyms and abbreviations
1. What would be a reasonable or acceptable response time for retrieval of a typical patent application in response to a query?
2. What would users consider an unacceptable response time for a typical query?
3. How many simultaneous users do you expect on average?
4. What’s the maximum number of simultaneous users that you would anticipate?
5. What times of the day, week, month, or year have much heavier usage than usual?
Sending a list of questions like these to elicitation participants in advance gives them an opportunity to think about or research their answers so they don’t have to answer a barrage of questions off the tops of their heads. A good final question to ask during any such elicitation discussion is, “Is there anything I haven’t asked you that we should discuss?”
Weigers, Beatty Ch. 14