Last Updated: 27 Jun 2023
|
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
processes:business-vs-technical-requirements [Feb 6, 2010 10:54 PM] dordal |
processes:business-vs-technical-requirements [Jun 24, 2023 05:07 AM] 111.225.148.53 removed |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | = Building Widgets: Business Requirements vs. Technical Requirements = | ||
+ | Have you ever built a widget? No, I’m not talking about one of those Mac OS X Dashboard Widgets, as cool as they are. Nor a Confabulator Widget, or a Yahoo! Widget. I’m talking about a good old-fashioned widget. | ||
+ | |||
+ | What’s that, you ask? Surely you don’t need me to explain a widget to you. | ||
+ | |||
+ | Oh, OK. Fine. | ||
+ | |||
+ | {{ : | ||
+ | Actually, a widget can be anything. **A widget something made out of something that does something.** Happy now? | ||
+ | |||
+ | Software people build widgets all the time. | ||
+ | |||
+ | The key property of widgets is that they are a small, defined ‘device’ of some sort, built for a single purpose. It may be to pass data from OmniCom International to Global Amalgamated Worldwide Design, or it may [[http:// | ||
+ | |||
+ | Either way, widgets – and all other software – need to have requirements documented before they are built. (Actually, there is some debate as to whether a widget whose sole purpose in life is to make fart noises needs to have its requirements documented, but we’ll pretend it does.) | ||
+ | |||
+ | What many people don’t know is that there are two types of requirements: | ||
+ | == Business Requirements == | ||
+ | |||
+ | Business Requirements tell you what a product is supposed to do. For example, “The widget needs to have the capability to make a randomly generated fart noise when clicked.” | ||
+ | |||
+ | Business requirements should generally be written by someone who understands the needs of the users of the software. Generally, these people have titles like ‘Product Manager’ or ‘VP Product Development’. | ||
+ | |||
+ | In some situations, it can actually be advantageous to have somebody //that does not know how to code// write these requirements. I can already hear the shrieks from the engineering teams out there, but hear me out: when you have these sorts of people write requirements, | ||
+ | |||
+ | {{ : | ||
+ | ==== Tips for Business Requirements ==== | ||
+ | |||
+ | * Keep business requirements simple, clear and concise. Simple sentences like ‘the application shall email the customer after they have placed an order’ is often enough. You don’t need to specific every last field on the email, or if you do it might be better to do it in a mockup (graphical form) rather than with the written word. | ||
+ | * Don’t go overboard on detail. Its tough for some people not to go into a lot of detail, but if you do you may lose people. | ||
+ | * Use lots of pictures, diagrams and (if you can) screen mockups. Even if these are just done in PowerPoint, it’s better than nothing. | ||
+ | |||
+ | I’ve written [[writing_good_functional_requirements|a whole article on writing business requirements]], | ||
+ | |||
+ | == Technical Requirements == | ||
+ | |||
+ | Technical Requirements tell you how a product is supposed to do something. For example, “The widget must have a module to display a picture of a whoopee cushion and a module to play fart sounds. The sound playback module must be built using Macromedia Flash and use the Flash sound library to interface with the hardware.” | ||
+ | |||
+ | Technical requirements MUST be written by somebody technical. (Surprise!) This person might have a title of ‘Software Architect’, | ||
+ | |||
+ | Technical requirements describe how a product needs to do something, and generally come in two forms: how the **architecture of your product should work**, and how it should **interface with other systems and software**. | ||
+ | |||
+ | **Architecture** answers questions about what each module of your software does, and how they should talk to each other. In the Fart Widget example, we have two modules… an interface module that displays a whoopee cushion and a sound module that actually generates a fart noise. | ||
+ | |||
+ | However, unless you spend your life writing fart software, your architecture will be a little bit more complicated. A typical web application, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Interface requirements** discuss what your product needs to do to operate in its environment: | ||
+ | |||
+ | //N.B. There are some who say that the architecture bits belong in a separate software architecture document. I’m not always a huge fan of this methodology, | ||
+ | |||
+ | ==== Tips for Technical Requirements ==== | ||
+ | |||
+ | * Remember there are two types of technical requirements: | ||
+ | * Use a lot of diagrams and visual aids if you can. They may take a little more time to create, but you’ll get a lot more buy-in. Don’t forget that there are templates and such to help you [[doc_templates | elsewhere on this site]]. | ||
+ | * Consider using a visual modeling language such as UML, but don’t let it bog you down. | ||
+ | * As with the business side, keep this simple. Let the engineer assigned to a module figure out how to make things work at the detail level – you just need to give them the big picture. If you go into too much detail, your company will be out of business before you even finish the plans. | ||
+ | * Make this a collaborative process if you can. Use whiteboards, | ||
+ | |||
+ | Happy Coding! |