Model Assumptions and Constraints

When an analyst is working through the information acquired from the elicitation process they will typically come across statements or conditions that are best described as Assumptions that have been made or Constraints that will restrict the solution is some way. These are not Requirements but have an important role in the requirements development process because they have the ability to affect the solution and must be understood.

Business Constraints

A Business Constraint is a business restriction or limitation imposed on the choices that can be made for the design, implementation or deployment of the solution. They are typically restrictions of budget, time and resources, but can be any type of limitation such as the context of the business deployment where the solution must not change the way that branch staff currently work. A Business Constraint might also limit the access or presentation of information such as 'Only the last four digits of a credit card number can be displayed in reports.' There is some overlap with business rules and the analyst should be careful to separate the two notions. Business Constraints can be modeled in Enterprise Architect using a Constraint element available from the Common toolbox page or a stereotyped Requirements element. They can be related to one or more model elements using a Dependency relationship. Constraints can also be created as a property of an element using the element Properties window.

Assumptions

An assumption is a statement that is believed to be true but that has not yet been verified. It is imperative that assumptions are modeled and attempts are made to verify them as they have the potential, if proved to be false, to significantly change the definition of the problem and therefore the solution. They can be statements made about the way things are currently done or they could pertain to a future process or solution. Assumptions are similar to Risks and good practice would prescribe them being managed in a similar way to Risks. Attempts should be made to verify them as early as possible in the requirements development phase. An example of an assumption is: 'The User will know the meaning of toolbox icons as used in other Windows applications'. Based on this assumption the solution designer might plan not to implement tool-tips for the icons. Assumptions can be modeled in Enterprise Architect using a Constraint element, available from the Common toolbox page or as a stereotyped Requirements element. They can be related to one or more model elements using a Dependency relationship.

Technical Constraints

A technical constraint is any restriction on the choices that can be made for the architecture, design, implementation or deployment of the solution. They can start with principles defined in the enterprise architecture that restrict the types of platforms, programming languages and decisions to buy or build part of the solution. They could also be restrictions on the type of protocols or standards that the solution must implement or comply with. Restrictions on file sizes and formats can also place limitations on the solution choices. There is some overlap with non-functional requirements and the analyst should be careful to separate the two notions. Technical constraints can be modeled in Enterprise Architect using a Constraint element available from the 'Common' toolbox page or as a stereotyped Requirements element. They can be related to one or more model elements using a Dependency relationship. Constraints can also be created as a property of an element using the element Properties window.