In Requirements and Life, a Picture is Worth a Thousand Words

Home / In Requirements and Life, a Picture is Worth a Thousand Words

In Requirements and Life, a Picture is Worth a Thousand Words

Words can often be one of the least efficient methods of communication. Indeed, language is typically not the most effective tool when we use it to gain agreement on design elements and systems design approach. One of the reasons we employ an agile development methodology is to allow our customers the benefit of actually seeing and touching portions of their solution — an experience that helps them refine or agree on a system design without parsing every word in a sentence and making sure everyone agrees on a definition. Over the past few years we have had success in extending this visual approach to the starting point of agile development – requirements definition – by using UML (Unified Modeling Language) diagrams.

Whether they’re replacing a home-grown system or looking to add a new level of functionality to their existing solution, Avanceon’s customers look to us to define their future system requirements and make the scope clear enough that a design phase can commence once we agree on them. Extending the ‘picture is worth a thousand words’ philosophy, we implement UML diagrams, especially Use Case diagrams, as a part of the requirements compilation and ultimately part of its deliverable. Such an approach helps clarify the requirements, especially when customers are impatient to get on to the development phase.
 
We start this approach at the initial review of collateral. Based on whatever information we have been provided or gathered during the sales cycle, we develop our first draft Use Case diagrams based on how we see people and other systems interacting with the system in question. We then create a Use Case Overview that maps out all of the Use Case Diagrams with an overview map labeled with general types of uses (e.g. Process, Execution, Quality and Configuration, if those make sense for the system we are designing). Then we include the diagrams (e.g. Process A, Process B, Recipe Configuration & Item Master, Lot Tracking, WOs & Scheduling, System Access, etc.) as circles in the approximate location that might best represent how they match up against those labels; it’s a good way to see a representation of all the system functionality at a glance.
 
Next, we create diagrams comprising all the actors and use cases that make up that particular grouping of functionality. We use these diagrams as talking points as we proceed through our interviewing and information gathering steps; we continually refer to and refine them as we better understand how things will need to work. The diagrams provide a good reference to ensure that we capture all the functions at a high level. This helps us focus on where we need more requirements or additional details.
 
We use these documents with our requirements tables to explain the requirements matching up with each use case. It’s an approach that give us a good blend of higher level requirements diagrams depicting the uses cases and the necessary interactions for all of the people and systems involved. The result is a more detailed listing of the customer’s exact requirements for each use case.
 
We’ve found this method makes it much easier to ensure we capture all the required functionality and get on the same page with our customers in regard to requirements details. It has also helped us reduce the time it takes to create and finalize documentation, and we’ve passed the resulting savings to our customers.
 
What about you? Has your organization developed some other, perhaps non-textual ways to develop quicker and more readily understandable requirements? What has or hasn’t worked for you in the past?
 
For more information about Avanceon project management, click here
 
 

Leave a Comment