6 thoughts on “Going further than monkeys: Let’s document requirements effectively”
Leave a Reply
Going further than monkeys: Let’s document requirements effectively
Select your location
English | EN
speaking about the need to documenting requirements has been beaten to death by now. i see articles speaking about this time and again. given that why is the other side of the story not given much focus.
the question on the other side is simple “why some projects do not follow a diligent requirements phase and documentation”
I think you got a point about a dilligent requirement and documentation. But why a phase ? By creating a phase you setup a “trap” for creating a big design up front.
I agree. In fact, I don’t propose to document requirements in a specific phase of a project. Regardless the project methodology, requirements always exists, although many times are not documented based on a strategy and are only in the mind of each stakeholder (each one with particular perceptions and expectations about a system). Although requirements engineering is usually conceived as a preliminary phase, requirements exists throughout a project (many artifacts, including implementation or QA artifacts need to be linked with requirements specifications and evolve/realize/assure them).
The point is trying to document requirements according to a strategy that avoids documenting with the purpose of making documentation useful for all the activities in a project that need to manage requirements (most of the activities, from development to QA have this necessity). In order to do this, you need to design, first, a documentation strategy, otherwise it is probably that the documentation will not be very useful nor aligned with the “big picture” of the project.
I think that this is a matter of project organization for investing in avoiding costly problems as soon as possible (PointZero -http://www.sogeti.com/pointzero- is about that and clearly states that as later problems are faced, more costly they are) or cutting costs of project knowledge management and “we will see”. The main problem is that many documentation does not rely on purpose-based documentation strategies to make it “fit for purpose”. In such cases, documentation (if exists) of requirements is, obviously, not useful and very costly, and therefore it is not valuable. A key aspect of project success is how we manage requirements and its impact, and it necessarily needs to rely on a strategy in advance.
If i understand it correctly you should start document effectivly first and when that’s done you are able to start developing ?
The idea is not only documenting effectively first, but also as soon as possible, and ensure traceability of such requirements specification throughout the project. For example, if a suitable requirements documentation strategy is previously designed and applied, then we can early detect requirements inconsistencies. If this inconsistencies are not resolved early with the assistance of effective documentation, then a conflict will probably appear later (its resolution cost will be higher).