After reading Software Design – Part 1, you have figured out what you are going to do by defining the goals for your software project. Now in Part 2, it’s time for you to start thinking about how you will actually do the project. Making the transition from a list of requirements to a design that satisfies those requirements is always a bit tricky because you have to translate real-world activities into something that a computer can work with. Even though you have a page full of requirements, you start with the proverbial blank page for your software design.
Don’t be intimidated. Although the design process is nearly as much art as method (no two developers come up with the same design), this article will give you a few proven techniques for translating requirements into software with a minimum of hair pulling.
The first thing to realize is that all software is about input, process, and output (IPO). Information enters the software through some kind of user interface or program interface. Your software transforms that information according to established business rules. Finally, information is stored, exported, or printed. Looking at your project from this perspective lets you understand how information needs to flow through the system.
IPO analysis is a good way to understand data flow, but it doesn’t do much to help you organize program components. At this stage, that’s fine. You can’t do an effective job of designing a solution until you fully understand the problem.
Analysis is breaking down a process to understand it. Design is assembling a process from your understanding. At this early stage of your application’s development, your goal is to perform as much analysis as it takes to get a feel for the scope of your project. Your analysis will help you identify natural groupings of related information and processes. As you understand more about what your application needs to do, you begin to form ideas of how you will build it. However, as soon as you start to design a solution, you discover the need to perform more analysis.
The iterative nature of analysis and design is normal and healthy. Your brain can only focus on so much information at a time, so it makes sense to break your application down into digestible chunks and cycle between analysis and design as you progress.
Use Scenarios
Proper analysis requires a lot of interaction with application stakeholders. These are the people who are paying for your efforts and the people who will be stuck using what you produce. Users don’t care about technology or elegance. They have a job to do. Software is nothing but a tool that, built correctly, will help them do their jobs better. Never forget that, and your users will love you and your application.
When collecting information from stakeholders, it helps to use scenarios. A scenario follows a single, specific business transaction through the proposed application. A scenario usually starts with a participant who provides some kind of input. The application processes the input and produces some kind of output.
Stepping methodically through each transaction’s scenario keeps everyone focused on one issue at a time, and makes it much easier for you to comprehend each process. Scenarios not only help you understand the desired interaction between the participant and the application, but they give you the opportunity to ask questions as you identify gaps in your knowledge.
Using scenarios is a great technique for collecting information, but you also need some good tools to help you organize that information. What follows are a few of the tools I’ve found useful.
Define Business Rules
The first thing you should do is start a list of business rules. Business rules can only come from someone who understands how the business operates. I usually write a business rule down as a simple, active statement. For example, when a stakeholder says, "I want to know who did what and when they did it," I might put down "the project tracks which users enter which information along with the date and time of the input."
If your application needs to validate input, assign a default value, or apply a calculation, write this information down as a business rule. For example, "transaction date must be today or greater" and "calculate the expiration date as today plus one month" are sample business rules that would affect your application’s design.
Define Terms
Another useful analysis tool is a term dictionary. It is a sad fact of life that every business discipline has its own jargon. As you assign terms to the information your application gathers and the processes it performs, you will discover that you are heaping yet more jargon onto the pile. Don’t fight it. Jargon is actually useful because it gives you consistent language for describing complex issues. A term dictionary will help you use your terms consistently and document them for later use by newcomers to your application.
A term dictionary is also very useful when the time comes to design an interface and database for your application. Consistent terminology makes an interface much more usable and code much more maintainable.
Define Roles
Almost every business application has to deal with user security issues. Rarely will you find an application where all users are allowed to use all functions. It is in your best interest to identify sensitive areas of the application and who is allowed to access them as early as possible.
Ultimately, security is all about users and permissions. Permissions identify secured application functions. If you manage security by user, then you have to carefully assign each permission every time you add or change a user. I prefer to manage security by role because you can set the permissions once for each role, and then control user permissions by assigning each user to a role.
For example, your application may contain sensitive payroll information that you only want payroll accountants to be able to see. One permission in this example might be "view payroll data," and a role might be "Payroll Accountant." If you hire a new payroll accountant, you can just assign that user’s login account to the Payroll Accountant role and he or she will automatically be able to access all areas of the application permitted to that role.
Be Patient
One of the hardest things about developing an application is having the discipline to perform an adequate amount of analysis and preliminary design. The temptation to leap into coding as quickly as possible can be overwhelming. Most developers don’t like gathering requirements and defining business rules. They want users to give them a specification that clearly lays out what is expected of them so they can just build the darn thing.
Your maturity as a developer will show in the patience you have to do the necessary up-front legwork. If you don’t set aside the time to figure out what it will take to do the job right in the first place, you will end up doing things over, which is far less fun, I can assure you.
