Good computer systems don’t just spring up of themselves, they require a lot of work from end users, consumers, managers, analysts, designers, documenters, developers and testers. These are all roles in the development process, it is not meant to be definitive, a single person may have multiple roles, a single role will often have multiple persons. For small systems a few people may occupy most of the roles, there may be a whole class of roles, such as stakeholders, who intersect other roles. In order to disentangle these roles and relationships and create a good computer system we use analysis.
Analysis is sometimes seen as an optional extra, on small projects where there is a temptation to start first and repent at leisure, on large projects it can get lost in a maze of priorities, lists and milestones, then repentance is less leisurely. Analysis starts with some introspection, and a review of where a project is at and where it is going. A good project is linked to a business initiative, but there can be cases where the computer system itself is the trigger for a remediation of replacement project. A useful ingredient is cost benefit analysis and risk assessment. These activities need to be conducted rigorously to ensure outcomes satisfy user expectations and that risks are acknowledged and ameliorated.
Having attended to the basic prerequisites basic prerequisites of cost and risk, the analyst’s attention must turn to the business domain. The analyst, or the team of analysts, will attempt to decompose the business problem into it’s component parts and interact with subject matter experts and stakeholders. One of the interesting things about subject matters experts is that they exist at all levels of an organization and may rarely get together to share their views, so discovery will be multifaceted at all of, and between organizational levels.
At this point many stakeholders will, no doubt, keen to see lists of requirements, process models and specifications. The Analysts will be trying to internalize a large quantity of information in order to create a broad brush design of a workable solution to the business problem. These goals and aspirations are not necessarily incompatible with each other, but they may not be naturally compatible.
The initial analysis and design process can be thought of as antithesis, synthesis and thesis. The decomposition of the problem domain is the antithesis, the design process is the synthesis and the design is the thesis. Ensuing iterations of the development process repeat this cycle, which can also be viewed as a continuous process, as synthesis continues until the goals are achieved.