Stephen Cohen's thoughts on Enterprise Architecture

Shredding Requirements

I spent most of yesterday going through 60+ verbose PowerPoint slides and 45 pages of detailed requirements.  You see I have a customer who has run into several issues rooted in their initial design considerations. They are a CMM level 3 organization with detailed procedures, voluminous documentation, and honestly it is not unnecessary.  They build large, complex systems and their end users require structured documentation.  

The requirements seemed to have been written after they selected and architecture and specific technologies, a serious no no. They had established nearly 30 requirement categories with low level must perform and shall provide statements.  There is a proposed logical architecture establishing 5 plug-able service modules and a core services ‘bus’.  Many of the requirements define object life cycle management and strive to maintain location transparency.  This all smelled to me like a JINI and CORBA based approach. Not the most unreasonable thing to do … except they are working with an exclusively Microsoft development environment.

My first goal was to shred these requirements into something I could get my mind around.  Focus on the “real” business requirements. Try to figure out just what where they trying to accomplish with location transparency? High availability and loose binding seems likely; both laudable goals for an enterprise caliber infrastructure. But I couldn’t reconcile the plug-able components.  Maybe they were looking for High cohesion within each component?

Using my favorite mind mapping program, MindManger, I began re-sorting each requirement, deleting duplicated, identifying orthogonal requirements and pulling policy or hardware related items into an out-of-scope category.  The result is a set of 11 services, each with 6 to 25 detailed, testable requirements.  For many I have been able to map them to existing Microsoft technologies (COM+ Enterprise Services, the COM hosting environment, the Enterprise Information Framework, etc … ) effectively removing them as items to be developed.

My next task is to establish a few high level use case documents and a simple block and line architecture model to present back to the customer and hopefully validate my findings.

 

 

Published Tuesday, February 10, 2004 10:58 AM by Stcohen
Filed under: ,

Comments

 

Wallym said:

I feel your pain.

Wally
February 10, 2004 11:41 AM
 

jdzions said:

How strong is the traceability of your shredded requirements? That is, will the customer actually *believe* that the re-sort you did completely covers the original set of requirements?
February 10, 2004 1:03 PM
 

stcohen said:

Traceability is a key issue throughout the process and I am glad you pointed it out. The shredding was intended to;

* Aggregate redundant requirements
* Highlight requirements needing clarification
* Discover holes where new requirements might be needed
* Begin the scoping the set of all known requirements down to a working set we can deliver on.

Keeping the customers confidence high is as important as making the best technical decisions. This is the first of several iterations each of which involve the customer, stakeholders, and existing developers. It is certainly my hope that they will feel comfortable with the results of the shred.

To more directly answer your question...
The original document followed a work breakdown structure assigning each requirement an ID like 1.2.5.5.12. I have attributed each of the resulting requirements with zero or more original ID's as needed.
February 10, 2004 1:16 PM
 

dave said:

Is there a written requirement for loan companies to shred personal documents?
June 14, 2004 10:32 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker