Requirements
Here is the thing - I think I would be described as old school. My first programming experience was creating code using punch cards. We would spend a couple of hours writing and then punching out our cards to have them returned the next week with program error written across the top of them.
I can remember when we followed the waterfall model of software development, then got confused by Boehm's spiral model, then got excited by the Rational Unified Process. Then along came pair programming, agile, extreme programming, Kanban boards, Post-it Notes, Jira and now we are in the age of AI vibe coding. Who knows what to do for the best outcomes?
My message is this: regardless of what you are doing and how you're trying to do it, having a decent set of requirements will be a thing of real value on your project. Requirements analysis, and the writing of requirements at the start will set the overall purpose, scope and "size" of the project.
If you have let a contract out to a software engineering company your requirements set becomes the scope of their work and lets you understand just how much they have actually done.
Similarly if you are a groovy AI codebot, that set of requirements lets you understand if you have done the right thing in the right way - oh, and just how much you have actually done.
It's helpful, and very old school, to create SMART requirements:
- Specific: requirement statements should be precise, detailed and clear and ideally define a discrete area of functionality.
- Measurable: it must be possible to measure some criteria to know that the requirement has been completed.
- Achievable: it must be realistic given available resources, skills, money, time and the state of the art.
- Relevant: the requirement must align with the project - form a coherent part of it.
- Timely: be possible within the timescales of the project.
If you can't write a SMART requirement it implies that you're either asking for the wrong thing or trying to create an impossible project.
Examples of things not to do:
- The system should be fit for purpose. Yes, good luck with that. The best thing to do is to define what fit for purpose actually means in a set of requirements.
- The colour of the thangdangle knob shall meet the expectations of the Aesthetics Committee. That doesn't tell me what the colour is, I can't measure it.
- The space vehicle shall be able to accelerate to 0.8c and decelerate to stationary in 24 hours. Yes, no. Humanity's science just doesn't know how to do that.
A decent requirement statement is also more than just the text of the requirement. A requirement statement should have the following components:
- Identifier: A unique identifier. It's always a good idea to number requirements in units of ten - 10, 20, 30 etc.. Then, when you find you have to create new requirements (which invariably happens) you have the space to squeeze them in in the correct order.
- Text: Your SMART requirements statement in all its glorious unambiguous prose.
- Rationale: A rationale for the requirement - why you want or need it. This is really important. Your project may last six months, it might last ten years. In that time things will change. By the time you get to deliver your requirement the need for it might have totally disappeared - or changed in a dramatic way. This helps with managing change on your project.
- Source: An indication of the business capability or organisational group that needs the functionality delivered by the requirement. This helps with developing test and acceptance plans.
- Links: Links to supporting material. Your requirement may be based on a formula or equation contained in a paper or standard.
You might do an initial high level set of requirements to get a feel for the kind of system you want to implement. In the case of the Cellar Door CRM this would help an initial market scan of CRM offerings. If the Cellar Door has its high level requirements, it is in a good position to see the offerings in the market that might meet those requirements. Following are some examples of the Cellar Door's CRM requirements:
R0050: Associated with an identified customer shall be their marketing preferences which includes their willingness (or not) to be contacted regarding special occasions and events, wine and dining offers and news about vintages and vintage releases.
Rationale: Promotion of the business to an existing customer base is a very important part of the marketing and selling functions. However, customers have to have agreed to receive marketing materials and have to be given the opportunity to opt out of receiving marketing materials.
R0060: A customer is able to record their marketing preferences via a form on the website or a paper form which can be completed at the cellar door.
Rationale: A customer has to have a way to express their desire to join the mailing lists and have their preferences recorded.