Role Activity Diagrams (a core component of Human Interaction
Management) were originally developed for industrial use as a means
of requirements capture that was also usable directly as operational
software. Over the years I have found them very effective as a central
technique in requirements capture - they are a clear and unambiguous
pictorial tool that is both liked by business people and amenable to
technicians.-- All the best Keith http://keith.harrison-broninski.info Robin wrote: Requirements & Specifications in Service Oriented Systems by Jeff Schneider <http://schneider.blogspot.com/archives/2005_11_27_schneider_archive.h tml#113318827766045648> << I couldn't help but notice that the cover story for CIO magazine was about the requirements process and the awful state that it is in. I tend to agree. When I visit customers I see one of two things: 1. The company has perfected requirements for silo based systems 2. The company stinks at requirements all together I've looked at many systems that people wanted to upgrade, rewrite or replace using service oriented techniques. As a habit, I ask for the original requirements document for the production system. I then play this game to see if I can trace 'silo' or 'closed' characteristics back to the orignial requirements and specifications. In general, these characteristics are usually described in the 'supplementary specification' or in a supplemental 'non-functional requirements' document. And in virtually every case I am able to trace the issues back to the original documents. One of the significant changes in the 'service oriented enterprise' is an renewed emphasis on: portfolios, product lines, business processes, enterprise requirements and cross-cutting concerns. We are stressing to our customers that they MUST revisit the requirements process and move to an 'enterprise grade' method.>>
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
