Terminology bedevils requirements. So here are my views on some common terms.
Business requirements generally define the problem to be solved. The general term we used in Telelogic's Professional Services was "stakeholder requirements". Some people divide these up into levels and differentiate Business and Stakeholder requirements, but they are really just different levels of problem definition. For example, the CEO's view of the problem is necessarily less detailed than that of the department heads. In terms of (at the risk of re-opening a different debate) "function", these requirements define what the business (or stakeholder) wants to achieve - the capabilities. But they must also define all those other types such as performance, security, usability, etc. - and if you don't like the term non-functional for these, then we used "constraint". It's not perfect, but I think it worked better than non-functional without some of the confusing connotations of "quality requirement".
System requirements define (but not design) the solution to the problem. Again, there can be (generally are in a non-trivial system) several levels, for systems, sub-systems, components, etc. In terms of "function", these requirements define what the system must do to provide the desired capability and we were quite happy to call these functions. Again, there will also be constraints in the system requirements.
Stakeholder and system requirements, especially constraints, can be identical. For example, physical constraints, such as a maximum weight, are often identical.
Oh, it is also important to note that you can't always (probably not in general) separate constraints from capabilities or functions; most (but not all) constraints are tied to a single capability (function) or a related set.
Business requirements generally define the problem to be solved. The general term we used in Telelogic's Professional Services was "stakeholder requirements". Some people divide these up into levels and differentiate Business and Stakeholder requirements, but they are really just different levels of problem definition. For example, the CEO's view of the problem is necessarily less detailed than that of the department heads. In terms of (at the risk of re-opening a different debate) "function", these requirements define what the business (or stakeholder) wants to achieve - the capabilities. But they must also define all those other types such as performance, security, usability, etc. - and if you don't like the term non-functional for these, then we used "constraint". It's not perfect, but I think it worked better than non-functional without some of the confusing connotations of "quality requirement".
System requirements define (but not design) the solution to the problem. Again, there can be (generally are in a non-trivial system) several levels, for systems, sub-systems, components, etc. In terms of "function", these requirements define what the system must do to provide the desired capability and we were quite happy to call these functions. Again, there will also be constraints in the system requirements.
Stakeholder and system requirements, especially constraints, can be identical. For example, physical constraints, such as a maximum weight, are often identical.
Oh, it is also important to note that you can't always (probably not in general) separate constraints from capabilities or functions; most (but not all) constraints are tied to a single capability (function) or a related set.
Powered by ScribeFire.
No comments:
Post a Comment