Without requirements or design, programming is the art of adding bugs to an empty text file.

You do have your Plan well under way... right?

Step Two

Software does not exist in a vacuum - it exists to solve a customer’s problem.

Questions to ask yourself

• Who is the “customer”?
• What problem does the project solve for them?
• What sort of data input/output is needed?
• Will you need to integrate with other tools or APIs?
• How will you handle security/privacy?

Answering these questions help you as you start to flesh out the requirements.

Capturing Requirements

There are may ways to capture requirements, but personally I find simple user stories to be an effective starting point:

As <role> I can <capability>, so that <receive benefit>

User stories can help you (and the development team) make sense of the functional requirements without needing to over structure the problem description.

Functional and Non-functional requirements

Broadly speaking functional requirements define what the system is supposed to do. Whereas non-functional requirements define how the system is supposed to be.

Okay so that’s a little abstract. Try thinking of the requirements as:

• the system shall do […] - functional
• the system shall be […] - non-functional

The ‘ilities’

Another way of thinking about a system’s non-functional requirements is as qualilities of the system.

• Availability
• Interoperability
• Maintainability
• Scalability

You get the idea.

Remember

• Keep requirements clear
• Keep the ‘WHAT’ (functional) separate from the ‘HOW’ (non-functional)
• Get help from the customer and your development team.