Currently we’re examining different ways of coming out with a second version of our shopfloor software, and there’s a lot of pressure to start rolling out a UI – even ahead of a stable data layer, or wireframes of how the end users want to have it interact and display information to our user base.

UI code is expensive. Putting a few days into asking some basic questions about unspoken requirements is cheap. Otherwise, you’re faced with the age-old “you gave me what I asked for but not what I wanted” relationship-ender that’s the bane of so many IT projects.

Usually business and user requirements will be defined (to some extent) at the beginning of the process. Let’s talk about system requirements – both functional and non-functional.

Functional requirements (what the system must do – “the system shall notify the administrator when a package fails) include things like the following:

• Business rules
• Admin functions
• Authentication, auditing, security
• External interfaces
• Reporting
• Historical data
• Regulatory requirements

Non-functional requirements (how the system should operate – “what’s an acceptable amount of uptime?”) include:

• Scalability
• Capacity
• Availability
• Reliability
• Recoverability
• Maintainability
• Performance
• Security
• Regulatory
• Manageability
• Usability
• Interoperability

Actual users will help you with the functional requirements; non-functional requirements will come from stakeholders. Once stakeholders are identified, you can gather requirements with a variety of methods (interviews, focus groups, questionnaires, observation (either direct or indirect), documentation, and researching similar projects.

Once this is done, you could split up your target audience into personas (including a name, photo, demographics, a descriptive paragraph, and needs/goals/features from a user perspective). Once this is done, you can refine your broad list of requirements into a very fine-tuned list of requirements – including a rationale, success criteria, and a level of importance. This key and often overlooked step will help you deliver a project that the users need, instead of just what they want.

For my project, I doubt I’m going to go as deep into the sensy-style personality demographics that some do – for an internal system we’re not customer-focused enough to care where someone falls on the liberal-conservative or trendy-status quo axis. But I will take the time to recognize that we have three user types – Operator, Engineer, Admin, and Executive – and split up broad requirements into a more focused matrix. This will give us an actionable list of to-do’s, so we won’t waste time writing UI code that doesn’t fill a specific need. Something like this…

 

As I refine this and get a survey going – our stakeholders are tied up 90% of the time in meetings, so an online survey on SharePoint or SurveyMonkey may be the go-to solution – I’ll create some new posts. I’m happy that we’re being a little more methodical in our second version of the software. Nothing’s worse than thrash when it comes to developer happiness and productivity!

 

Helpful links:

• Gathering nonfunctional requirements (source of functional reqts triangle above)
• The famous How Projects Really Work poster (a classic)
• A great breakdown on nonfunctional requirements on this page.