I have a problem on how to advice SMEs on the simplest, value added way to implement RD P 3.1 Establish Operational concepts and Scenarios. In which specific work products can we see the development of operational concepts? Is it ok to say that you can see the operational concepts reflected in the following work products as they are refined: non functional requirements, design restrictions, system architecture document, installation manual, deployment diagram, package diagram, component diagram?
First let's take a look at why RD.SP3.1 is even in the model.
Sometimes it's difficult to visualize the feasibility or reasonableness of a requirement without putting it in context. This is one reason prototypes are so popular - they literally paint a picture of what the implementation might look like. When they see this users often say "no, that's not what I meant" or "what would happen if we tried this?" This is a form of requirements validation.
RD.SP3.1 is asking you to validate requirements by putting them into some context.
The simplest and most useful way to do this is with a Use Case, User Story, or Storyboard. They require only a marker and a whiteboard, or software like Visio, to implement. They're extremely valuable at putting requirements in context, and they're low cost, low effort.
Developing a prototype for a more complex requirement, or a proof-of-concept (a "spike") is another way, albeit more costly, to drive out pesky requirements defects.
The other artifacts you've listed seem more like they belong in the Technical Data Package (design documents from TS) rather than in RD, with the exception of non-functional requirements, which need to have RD SP3.1 performed against them to be completed.
http://www.broadswordsolutions.com/
No comments:
Post a Comment