TOGAF – Requirement Types

Karl E. Wiegers, in his book Software Requirements (2nd ed, 2003), identified the following requirement types.

I’m breaking them out further (with thanks to Steve Corlew, the TOGAF certification trainer I worked with) into 2 sections…General Requirements and IT Requirements.

We are going to use purchasing a new presentation development tool as an example.
Because everyone hates PowerPoint (apparently).

Examples (or the types of things you are likely to hear) are in italics.  

General Requirements – these will be guided by the Architecture Principles

• Business Requirements – what the business is trying to achieve
• “The business needs new presentation software that allows us to reduce presentation development time and automates presentation hosting to our website”
• User Requirements – what the users need to be able to do
• Example: “Users need to be able to edit a presentation built in the solution”
• Functional Requirements – what the solution (software / hardware / network / other) needs to be able to do to allow the users to do what they need to do (User Requirements) and help the business achieve it’s goals (Business Requirement). 
• The details of what the solution needs to do.
• Example: “Upon publication, the presentation will automatically upload to our web server.”
• Functional requirements for a system are often broken down into the different components of that system.
• Example: if the system to automate presentation hosting to the website includes the presentation tool, a tool allowing upload to the web server, and the web server…the Functional Requirements will contain 3 different sections. One for the Presentation tool, one for the upload tool, and one for the web server
• The sections separating out the different components will then be further broken down into Features – or the collection of  “logically-related” functional requirements that provides a capability so the user can do what he/she needs to do and to help satisfy a business objective.
• Example: Submission of Presentation to Web (incomplete, but you get the gist…)
• Requirement 1: The tool will allow the user to save a presentation without submitting it for approval.
• Requirement 2: The tool will provide the ability to notify a designated “approver” that a presentation is ready to publish to the web site
• Requirement 3: The tool will allow the approver to click a button and post the presentation to a designated location in the web site
• System Requirements – the top-level requirements of the entire system.  When everything is put together, what does the system do?
• “But,Wendy – we just want new presentation software! I’m not worried about a system!”  As soon as you are interfacing with anything else – you have a system.
• Are you trying to display the presentation on your device onto a screen in a conference room? You are working with a system that includes 
• the actual presentation software you selected
• the device you are using (Mac, PC, iPad, Kindle, Smartphone whatever)
• the projector in the room you want to use and any cableing
• any application you are using so that your device can broadcast to the projector (if it is not already built into the operating system)
• any
• System requirement = Users can show the presentation through a projector onto a wall. 
• Sounds simple, but how many times have you found yourself scrambling for converters (Mac or alternate device users who don’t have built-in VGA ports) or fought with the wi-fi/bluetooth settings on either your laptop or the projector. Or is that just me….

—————————–
 IT Requirements – what your IT developers need to help build the system of your dreams

• Business Rules – corporate policies, government regulations, industry standards, definitions of particular terms (eg. a “student” is an individual who is registered for at least one University course offered through the Registrar’s office.).
• A good resource for helping you determine what business rules you need to collect will be the Business Analysts housed in the IT Department.  
• The more refined you are able to make the business rules, the more the IT folks can help you.
• “Who will have access to the presentation tool?” Business rules will help define the access.
• Quality Attributes – these attributes are essentially further detail for each of the Functional Requirements. Acceptable time between screen refreshes, readability of buttons, that sort of thing.  
• The questions your IT developers will ask during the course of the project as they build out the solution will likely be about quality attributes.
• “How quickly do you need the presentation to show up on the website? Does it have to be immediately or can it be the next morning?”
• External Interfaces – the interface between this system and other systems. 
• “How does the presentation I developed using the Presentation software show up on Slideshare?”  Slideshare is the external interface.
• Constraints – what in the existing system can’t be changed. 
• “Everyone we work with still uses PowerPoint.  Therefore, the Presentation application we choose has to be editable in PowerPoint.” Unless you can somehow get everyone you share presentations with EVER to switch to your tool – this is likely a constraint.

——————————
I know this seems like a lot…but the time spent fleshing out requirements helps make sure you are actually building a solution that solves your problem and gives you a better shot of selecting pieces that fit your needs (vs fitting your needs to the pieces).

Even better, when we are ready to re-evaluate parts of our Ecosystem, we already have a baseline to start with!