Sunday, April 30, 2017
26

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

On the surface, the business needs between your previous requirements document and the current document may not appear to contradict or intersect, but the way that the developer or engineer choose to build it was not flexible because they didn’t know changes or additions were coming. A different approach to coding, such as making calls to a database instead of hard coding in data, can save hundreds of developer hours (and speed the release of your product or service) in the future. Hardware can be even more time-consuming to rebuild. If an analyst specifies a requirement to include one network drop in each department for a new building, and later the business owners decide each department needs five drops, the network engineers have their work cut out for them. It is incumbent upon analysts then, to write requirements with an eye toward future development needs--some of which are invariably unknown.

Here are some simple practices that can help you shape your requirements with an eye to future development:

It may seem obvious, but note future considerations in your requirements. You may include this in your exclusions section if you have one, or in your general business requirements. Example: “Exclusion: This process will not automate order entry. However, this is a future consideration.” If you believe there's a chance that management may want to add or extend a process in the future, note it for your readers.

Beef up your assumptions section. Any assumption section is often short in a requirements document, but if you take the time to think it through, you’re almost always assuming a lot that needs to be documented. Example: "Assumption: This order process will be made extendable so that when future products are added to inventory, they may be ordered in the same way." Or, as in the example in our introduction, if the requirement is truly to only have one network drop in each department now, you can still advise the administrators to be flexible in their set-up. “One network drop will be added to each department. This build will be extendable so that up to five additional network drops can be added in the future, if needed.” (This way, the administrators can just go in and run the cables without possibly having to tear out a wall.)

Requirements have to be specific, but what’s specific can also be broad. There is a difference between being vague and being open. “A notes field will be included,” is vague. “A simple text notes field will be included,” is limiting (but perfectly accurate if you’re certain there will never be a need for rich text formatting). “A rich text notes field will be included that will accommodate 18,000 bytes. The database where the notes are stored will be flexible to accommodate more data, if the need if determined in the future,” is open. Choose limiting requirements only when you’re sure that’s all your stakeholders will ever need.

Consider breaking your requirements into phases. For projects that are truly massive undertakings, it may be wise to break your requirements into segments. Projects of a large nature tend to change over time. As industry buzz spreads at trade shows and among sales reps, business owners get more feedback. Mock-ups and prototypes are passed around. Beta versions are offered to select customers. And your Beta customers may ask for functionality you never dreamed of. Start with the basics, working collaboratively with your engineers. Of course this approach will have to be signed off by your stakeholders, but it lessens the pressure to get everything right from the start and increases the chances of a smooth development cycle as you progress.

Attend a broad range of organizational strategy meetings, and ask that developers do the same. If managers and business owners are the only personnel coming to strategy meetings, they may not think to tell analysts and developers what is planned three months from now. Simply having an overview of the possibility of future endeavors can affect the way that developers build now.

Include a company strategist in your requirements reviews. You may even want to give him/her a preview of your scope before showing it to the rest of the group. This will help ensure that any developments coming in future months are respected in your current requirements.

In your requirements reviews, be sure to mention future considerations, assumptions, and flexibility aloud, and ask for feedback. Since, unfortunately, some team members may not read every word of the requirements carefully, bringing future considerations to their attention in a group will help ensure that they make it on their radar.

If other business analysts work for your organization, work with them to create a flow chart or diagram to identify dependencies and areas of overlap between projects that you are currently working on or have been assigned. Try to attend at least one requirements review for each of your colleagues’ projects, and ask that they do the same for you. Shared needs will begin to emerge. For example, if you have a project planned to allow customers to upload data, and your colleague is working on reports, you’ll want to ask him or her to include a unique identifier in the report data elements to enable you to match the reports on upload.

It’s impossible to write requirements that anticipate every possible future development scenario, but as you incorporate these practices and also interact more closely with engineers, developers, organizational strategists, and other analysts, you will all begin to work together thinking more critically about future development needs and how what you’re doing now affects them. Your team will start to focus on flexible requirements in concert, and the onus of considering what may come three or six months down the road will be shared.

Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com

Post Rating

Comments

There are currently no comments, be the first to post one.

Post Comment

Only registered users may post comments.
Copyright 2009-2014 by Modern Analyst Media LLC