The Elaboration Formula

You have finished your requirements gathering and now need to convey your vision to the software development team, where do you begin?

I start with the following formula: View, Create, Edit, Delete, and Print. These are the five primary ways a user will interact with your software application.

Although this conversation is directed at the new software business analyst, even those with experience can occasionally face a bit of writer’s block. If you get the basic foundation laid then you can concentrate on the complexities of your feature.

View

Is this totally new or a modification to existing functionality? Can it be seen in your application today? What needs to be added here? An entire page, grid, report or just a field? How does the user navigate to the functionality? Do we need a new menu option or a button to launch a new page? Laying the framework for the new functionality is often the hardest thing to conceptualize. Take a step back and put yourself in the user’s shoes.

Create

Is the user going to create or add a new record? What fields are needed? Which ones are required, and which are optional? What happens when they save the results?

Edit

Can the user edit or modify an existing record? How do they tell the application that they want to make a change? Are the fields always enabled or do they have to select an option to edit?

Delete

Is the user allowed to delete a record or must it be marked as inactive? Is the record archived or does it persist in the database?

Print

Does the user need to print the results or just view them on the screen? How should the initial display be sorted? Do they need to option to filter the results in some way? Are we printing as a PDF, to Word or both? Is there a business reason to export to Excel?

If your feature is to create a new report, you may be looking at additional inputs to pull different subsets of data. Titles, dates, page numbers, headers and footers will come into play. How are sections grouped and totals displayed?

Other Considerations

What else do we need to consider? Permissions is the first one that comes to mind. Can any user complete all these actions? Are only certain users allowed to delete? Does your application have an existing permission module that needs to be modified?

What are the business rules or constraints that need to be implemented? Do we warn the user or block them from certain actions? Do your data entry fields have character limits or do they need to be unique?

Does this functionality impact or integrate with other areas of the application? If new fields are being added, do they also need to be added to existing reports or dashboards? If you are working with a robust or enterprise application, it may be handy to have a checklist of the potential areas of impact.

---

---

What does it look like?

Some teams may include a UX designer, but more often a business analyst must create a initial mock-up of the new functionality. This may be a drawing on a whiteboard with input from your team or be created digitally so that it can be sent to stakeholders for review. A picture says a thousand words can quickly convey your concept and generate insightful questions.

Putting it to paper

How you document this for your team depends on your current organization and methodology they use. A traditional functional spec or design document will spell out the solution in detail and typically includes a mock-up of the new screen/grid/fields/report. A use case document will detail the interaction between the software and the user. User Acceptance Criteria will speak to the basic requirements that the user needs to accomplish for the user story to be marked as DONE. They are all conveying the same vison in a different format.

• Design: Add the new functionality button in the application location.
• Use Case: The system displays the new functionality button in the application location. The user invokes the new functionality button. The system displays the new functionality page/grid/report.
• User Acceptance Criteria: The user can view the functionality name in the application location.

Many organizations will have a combination of documents that are needed to get a requirement from concept to development complete. Elaboration is just one step in the development process.

Don’t reinvent the wheel

Unlike writing your college term paper, elaborating requirements and writing user stories is not graded on originality. It is actually more productive to borrow or re-use sections from similar functionality documented in a previous sprint or release. Your team will be more comfortable with the steps that were used before and you have a reference to ensure that all areas are covered. Review the defects, linked stories and documents to see if anything was overlooked in the previous endeavor that should be included upfront this time.

Create your own Formula

This formula might not be the best for your specific project, but it might help you create one that is. What steps come to mind when you receive a new feature? Is there a mental checklist that you follow or one at the back of your documentation template that covers impacted areas? Is there someone on your team that has a knack for taking a new feature and running with it? They probably have a formula in their head that they are unconsciously working through. Find your formula, rinse and repeat. Build better software.