This item (http://www.dataweek.co.za/news.aspx?pklnewsid=39316) focuses on engineering requirements and solution vs enterprise requirements and solutions.
Nevertheless some of the issues they deal just as relevant at a business or enterprise level, as they are hard to deal.
They are mainly hard to deal with as a result of misapplication of techniques that are well suited to engineering electronics (or software) but very poorly suited to architecting a business. These techniques are dragged into the enterprise requirements domain by technicians or consultants. It is as if we have allowed the languages and techniques of the plumber, or the electrican to be foisted on the town planner.
Extracts from the item below in italics with my comments
...focused on requirements and the proper management of requirements throughout the process. [yes, obviously critical. So it is pretty why a static document e.g. a requirements document won't do the job]
... requirements must be captured, reviewed and validated, managed and traced to design implementation and verification activities. .... a checklist of criteria against which you review the requirements .. a method to link requirements to the design implementation...
[Yes all necessary. At an enterprise of business level I refer to "Acceptance", "Acceptance criteria" as the process use to Verify results. We use this terms because it is business and contractually oriented term i.e. to distinguish from whatever testing/validation engineers (or suppliers, or sub-contractors) might seek to do.]
... Tracing requirements to design implementation and verification results
[made difficult by]
... requirements can be volatile [i.e change. Obviously they change]
... the mechanism to capture requirements is disconnected from the design environment [in a business context one needs to ask why. Really what they mean is that the requirements are disconnected from the engineer environment and there is no discrete design environment per se. That is why we focus on Solution Management and ensure the management of the solution discrete from the engineering of the elements of that solution. A lot of the complexity in business technologies results from failure to define and manage this boundary]
... often takes an expert to do any sort of ‘management’ of the requirements [in business context this is simply not viable because we need the business knowledge to define requirements. We must find a way they communicate and manage their needs]
... the implementation and verification of requirements occurs within a variety of environments and tools, each with their own language, format, process, location and experts [again in a business context this can not be case with acceptance of a solution by a business user]
... link requirements from the highest system level to the lowest-level implementations of hardware and software. [and what businesses need is to link requirements from the highest level of the business to the lowest level component that they pay for discretely. Things beneath this level are necessarily encapsulated be the bespoke of off the shelf]
... Requirements changes, and their downstream impact, are all highlighted ...
... Requirements validation checklists are both built-in and customisable
... Requirements traceability is automated and up-to-date with the design
[yes, yes and yes]
... After all, what company wants to produce a design that does not meet its requirements? What company wants to stand up in front of their customer and say “We have finished your design, but it does not do exactly what you want.”
[Or we have completed your expensive projects but they have not met the shareholder's or stakeholders requirements to produce value or outcomes]
No comments:
Post a Comment