The ultimate goal of a software program is to solve a problem. The problem can be simple, such as a software program that checks for misspelled words in a text document, or complex, such as a software program used to create a database. Regardless of the problem, if the software program does not effectively address the issue and provide a means for the user to create a solution, it is not effective and falls short of its goal. Writing good software starts with an analysis and design document that addresses user requirements and creates a plan for providing solutions.
Define the Problem
Evaluate the request by first looking at the bigger picture. Make sure you understand what the user is asking for. Ask probing "who, what, where, when, why, and how" questions to get to the root of the problem.
Define project scope and constraints. For example, if the request is for a software program to computerize a book-ordering system, evaluate the current ordering system from beginning to end. Define and establish project boundaries and identify project constraints you must work within, such as existing hardware or a limited timeframe for project completion.
Look at the end-user. Interview and observe the people who will use the software on a daily basis to determine how the software must function to accommodate the request, and how you can design the new system to best suit user needs. Identify user-related factors that may affect the project, such as how the skill level of end users may affect training requirements.
Determine feasibility and present recommendations. Provide a written evaluation of the request to include an estimate of costs, benefits, timetable for completion, and your recommendation as to whether the software will effectively address the stated problem.
Prepare the Analysis and Design Document
Develop a data flow diagram and process description. A data flow diagram explains what the program will do and a process diagram displays how the software program will do it. For example, a data flow diagram and process description for a book-ordering system would document and describe the process, step-by-step, from selecting the appropriate book to entering the book into inventory.
Create a data dictionary that defines and describes necessary data elements and combines these elements into data records. For example, in the book-ordering system, examples of data elements include book name, ISBN, author, and price. These elements then combine to form a book record; other elements, such as the vendor name, account number, and sales rep, can combine to form a vendor record.
Combine the data flow diagram, process flow descriptions, and data dictionary into a document package that describes the software program in a logical, written format you can use to create a program prototype, or working model of the software program.
Things You'll Need
Software request details
Business rules, procedures
Access to end users
Presentation software (optional)
A benefit to clearly defining project scope is that it helps to avoid “project creep” that can occur when a project grows beyond the initial request.
Another idea for identifying end user requirements is to develop a survey using a combination of open-ended questions, closed-ended questions, and range-of-response questions. Include questions such as “What features would you like to see in the book ordering system?” “How many book orders do you place each month?” and “On a scale of 1 to 10, how would you rate the inefficiency of the current book-ordering system?”
In addition to presenting a written analysis and design document for a software program, it is sometimes helpful to use presentation software to add a graphical representation of the new software system.