No matter the field of study, systems analysis involves breaking a large complex project or product into small, manageable parts so each may be designed, studied or analyzed in detail. The tools an analyst uses have not changed much over the years and do not require high technology.
Often the first step involves determining whether the product or project is worth the time and effort. A feasibility study is a document that describes features and benefits of the product, itemizes costs, resources and staffing then describes the projects potential profits or value to the organization. A feasibility study forces the analysis team to turn a nebulous idea into a practical, useful project with a firm definition and a list of tangible benefits.
The details necessary to understand processes or product needs are usually in the heads of employees and customers. The only way to mine this information is to talk with them. Interviews should be focused, with a prepared list of questions or concepts to be discussed. Document each interview by recording it using a small digital recorder or summarize the conversation immediately after it is completed.
Short narratives describing how a product will be used, limited to a few paragraphs, often helps analysts and customers refine product features. Refine these narratives throughout the analysis phase. These use cases can be used throughout the project life cycle, especially during testing.
When designing a product, it is helpful to keep a running list of requirements. These should be presented as a list or in outline form, organized by categories. As the list grows, this list helps the analyst understand the customer's needs and helps limit what features are necessary and which are not.
Flowcharts come in many varieties and under many names, but the basic concept is to take a process and describe it as a diagram. Whether presented as a process flow chart or an Entity/Relation diagram, the drawing helps the analyst describe a series of steps or decisions in visual form in a manner that facilitates communication.
A model or prototype can turn a group of ideas into solid form. Software engineers often hear the statement "I'll know what I want when I see it" and a model or prototype can facilitate these issues. By presenting a prototype, the analysts gather features that work and open discussion on other features and improvements.