Defining What You Need: Firming Up the Specification
This is the third in our series of articles on How to Ensure Software Project Success.
By following this course you can gain the benefit of Visichain’s vast experience across many projects and tens of thousands of hours of development work in the complex industries of supply chain management and logistics.
Clarifying the Specifications of Your Software Plan
Here we’re going to show you how you move forward from the initial set of confirmed Solution Requirements to firm up the specification of the system or app you plan to build.
When we say firm up we mean that you will add more detail to the requirements, come up with a tighter cost model (by feature), rationalize and check the prioritization of the requirements, formalize the user and system flows – and cross check everything.
You also will need to settle on a final choice of the technology options plan to utilize. The result will be the System Requirements Specification.
Before we do that, it’s worth remembering that the best software development is an iterative process and you will probably come around this cycle again as you learn in more depth about what you can and can’t expect to achieve in the your initial Version 1.0 build.
For example, features you want might require third party technology, i.e. middleware, or they may incur a build cost which would price the final product out of the market–making it a poor business decision to move forward–or which your budget will not suffice.
Decide What Really Matters: Prioritize the Requirements
Now you have the information about the solution, the cost estimates, the Business Analyst will liaise with you (the client) and help you to prioritize the requirements. This is where the Business Analyst adds more value.
You are not throwing anything out at this stage, just confirming the functionality that will be built in the first version – and that it is within budget. Other functionality may be delayed until a later version.
To ensure both budget and timescales are achievable you go one step further and prioritize the functionality within the first version.
In an the agile scrum development process the build is made up of a series of sprints – or development cycles building out functionality progressively – delivering additional features sprint by sprint.
When you set clear priorities within the version 1 requirements then development snags need not cause delays. You just reschedule the ‘desirable’ items for a later stage.
This means that the minimum viable product, MVP, is achievable within the timescale and you have all the ‘must have’ functionality in Version 1.0.
Sharpen the Focus: Formalize User and System Flows then Cross Check
In this step, you or your development partner will formalize the user and system flows.
In simple terms this is how the user will interact with, say, the video streaming app, and how the data stream will be delivered and presented on the target platform(s).
This check covers all the users, including your support desk and managers – maybe even your finance users on the billing side.
More Nuts and Bolts: Technology Options
Continuing with the video streaming example, the broad architectural options would range from using a simple server to using a content delivery network, CDN.
The options will need to be considered right through the application to the presentation layer and user interface, UI, on the target platforms.
The options will need to be assessed with the pro’s and con’s (including risks) – and costs – being identified.
If, for example, the Business Requirement is to deliver a video stream to the iPhone platform only, then there are Apple-specific options which may be simpler to implement.
Some options may be more costly initially but would enable a shorter implementation timescale. This could give you earlier benefit flow – revenue or business efficiency gains – maybe both.
Requirements and Cost: How Much for This Video Catalogue View Format?
This work is usually done by the Technical Lead, the senior software engineer on the project, someone who knows that the devil is in the detail, and that the last 5% of functional nicety – say a particular should have video catalogue view – can be the most expensive to build.
This costing is usually done by estimating the amount of work involved in each piece of functionality, not forgetting that the functionality has to hang on an architectural framework which may have a cost – and that will depend on the technology to be used.
Depending on the particular project it may be that a range – ‘low’, ‘most likely’ and ‘high’ estimates will be produced, and they may be produced against a range of technology options.
Rolling Up the Costs: Final Estimate
All these costs are then rolled up into the final estimate.
This is a critical checkpoint, where you confirm that the user and system flows match the product vision – and that this budget is acceptable.
Some changes are often made at this point, better now than later.
You might have to drop one or two functional niceties from version 1 and schedule them for a later version when your app is earning its keep.
However, it is at this point that you should expect to commit to a specific technology option.
Closing Remarks: Your Product Vision Crystallized
So, you now you know what you will be getting at a minimum, at least in version 1.0.
You have confirmed the content and fined-tuned the solution requirements specification.
You have reviewed and approved an overall cost estimate for the whole project, so you know what you will be getting – and for how much.
In the next article we will be looking at the next step along the path as you discover how to Ensure Software Project Success when the first prototype is built, read on >>> How to Get Stakeholder Buy-in: Building a Prototype.