It has always been my view that requirements are part of the design process. If you start with a list of "musts" it is very likely you will find the software that needs those musts will not adequately meet the users needs. Sometimes the users needs are met but the software is still less than it could be.
During decades of software development and system implementations, it has been my experience that after the software engineer has designed the system to meet the requirements he understands what the user actually wants to accomplish and would do it differently if time allowed. I have had many experiences where we have developed to a spec, received high praise from the users and with my newly acquired knowledge of the problem domain, asked the user a few "what if"s only to find we could have provided a significantly better system because the user had never thought of doing the task in a different way. (Here is a great article by Mike Cohn about this phenomenon.)
In his book "Software Project Survival Guide", Steve McConnell identifies three intellectual phases of a software development project. He calls those phases Discovery, Invention and Implementation.McConnell lists "discovering the user's real requirements", technical investigation and building prototypes as activities in the Discovery phase.
In my experience the best solutions use the most skilled people in this phase. It is the most likely predictor of success or failure. Failure in discovery makes is very difficult to succeed in implementation.
Yet, when you think of the tools we use to aid in the discovery phase, what comes to mind? There are use cases / user stories, UI prototypes and requirements documents.How can one capture intent? This is my current struggle. I believe this to be one of the glaring holes in the tools available to aid with the software development lifecycle.
Of course, this is not just my opinion. Others have said this and even offered some ideas to address it. Sriram K. Rajamani states "the biggest problem in software engineering continues to be the bridging of the `gap' between the intent captured in requirements and expressed at a high level, and the detailed encoding of this intent in the code. There are no good tools, either mental or mechanical, that allow comprehension of large programs, and provide a mapping between how different parts of the code work together to satisfy the requirements.Thus, looking for any high-level requirements within a million line program is analogous to running around New York City looking for a lost cat, without a map, and without any street signs."
I would move the "biggest problem" up stream slightly to bridging the 'gap' between understanding what the user truly wants to accomplish and how to best leverage technology to help accomplish that. However, we agree on the issue. There are no tools to allow the business analyst, the software architect and the software engineer to capture what they understand. The only options we have is to capture what we have concluded is the solution.
For example, we may have a list of requirements that have been tediously recorded. What we won't have is the information that was discovered that lead to those requirements. Why is this important? It isn't important if you only want someone to design a system to meet the captured requirements. However, if you want to invent something that will actually add value to the job at hand it may be very important.
My proposal is to combine disciplines and tools. I propose that software projects should team business analysts and architects in the discovery phase. I propose we build a set of tools that combine a good narrative , use cases / story cards and technical diagrams into an interactive, connected modeling environment that allows an analyst to link multiple types of content and define the types of links. Text elements could be linked to other design artifacts like UI prototypes, UML static and dynamic diagrams. I can imagine a narrative explaining why a user currently performs a particular task being linked to a use case, a number of derived requirements and even an activity, sequence or state diagram.The derived requirements could also be linked to UI prototypes and UML classes that realize those requirements.
Here is a list of the attributes that a system of this sort may need to have.
- Objective: To provide a means of capturing the intent of a software development initiative including the problem domain and desired outcomes.
- The Target Audience: Outcome Stakeholders
- Content Properties
- Multilevel - Captures the highest level of intent to the lowest level of detailed requirement or design - Captures highest level of abstraction to the lowest level of concrete implementation
- Connected - Associative / Relational - identify and document the associations and dependencies and use them for tractability - able to trace from the lowest level of detailed design to the highest level of intent
- Multifaceted - multiple perspectives or aspects
- Process view
- Requirements view
- Data view
- Workflow view
- User Role
- Security
- Accessible - Available and understandable to all stakeholders
- Maintainable
- discrete elements that can easily be modified without major impact to other information
- Revisionable - able to fit any sane view of revision / change control
- Comparable - able to compare iterations
- Interactive - electronic interactive document with the ability to produce static, printable documents for all or portions.
Over the next several articles, I intend to flesh-out the essential components of such a system and give a few examples.
Tory
