My Process

It's not often we're able to follow an ideal process from beginning to end while working on a project. There's always something that takes us in a different direction. Although there's a difference between knowing the path, and walking the path, it's still reassuring to know the path is there.

In this section I outline my ideal approach and process to developing software. I cover all stages of development, all possible deliverables, and all areas that may need special attention. I don't follow all steps in every project, but with this roadmap I can always visualise where I stand.

SDLC

Most descriptions of the System Development Life Cycle (SDLC) identify 5 to 7 stages, a combination of Requirements, Analysis, Planning, Design, Development, Testing, Deployment, and Maintenance.

In my process these stages are grouped into three main phases:

• Design phase

• Development phase

• Deployment phase

Each phase is an interative process with an identifiable set of goals and deliverables. The whole process usually repeats, resulting in several rounds of incremental delivery.

While each project will emphasise different steps and have overlapping activity, these broad phases are a good way to identify overall progress.

Design

The primary goal of the design phase is to prepare sufficient documentation for developers to begin work with confidence that the system is achievable. It can also provide the customer with predictable costs and timelines.

There are several crucial steps to the design phase that set a project up for success. These steps can seem tedious, but getting the core application requirements correct and concise can have great benefits throughout the project, so it's worth taking the time to do well.

The steps are:

• Requirements gathering

• Analysis

• Design

• Planning

The design phase begins with requirements gathering, usually by meeting with the client. However, it is an iterative process, and you will likely meet with the client two to four times before completing the phase.

Requirements gathering

The requirements gathering step involves sitting with the customer and listening to them describe the system they need. It will be a mixture of general and specific statements that will describe processes, artifacts, outcomes, stakeholders, and more. Listen very carefully, and note down as much as you can. Try to keep notes in the customer's language - you want to absorb the domain lexicon. But, be open to differences in interpretation - clarify your understanding with questions. You should spend 80+% of your time in this meeting listening to their problem, and not foretelling a solution. Prompt the customer with questions they may not have considered. Be sure to clarify the customer's actual business objectives, and consider if stakeholders not present have separate requirements.

Work collaboratively on a context diagram that shows how the existing processes and systems function, and where the proposed system fits - this will help clarify your understanding and reduce ambiguity later. If the client is unsure of a solution, you have an opportunity to propose options. The discussion may turn to buy-vs-build, business scaling, or vendor partnerhips - anything that may not be a software build project. This guide does not cover these options, but you should consider alternative approaches. (Cuation - be patient, the client is an expert of their domain, but they may not be used to explaining it in systematic terms. Stay focused on the problem space, with enough context to understand inputs and outputs).

Requirement gathering sessions may feel like an interregation. Warn the customer you're going to be pedantic and ask them for patience. Explain that computers do exactly what they are asked, so we can't be ambiguous. However, if you get stuck on a trivial concept, don't labour it - make a note to come back later and move on.

With experience, you'll find you're asking questions to clarrify things which the custopmer does not understand the relevance. You're using your experience to think ahead, and some details will help you identify which options may or may not be possible. For example, do they really need X, or was that a casual assumption? If not, then we won't need Y, which will simplify development. Try to get the customer comfortable with answering seemingly silly questions. Say you're like a child, bumping in to things to see the possibilties, and you need everything explained. (caution - read the room. The client may expect you to know more than you do, so approach this by explaining that you're ensuring you're on the same page, but learn quickly).

Another approach that may be helpful is to ask the customer to prepare a brief that outlines the system. This might be one to four pages. Anything longer and it's likely to be describing a solution - this should be avoided as you should be involved in the solution before it reaches that level of detail.

After the meeting, organise the notes into a consistent narrative. Organise concepts together, clean out redundancies and prepare a review document of everything discussed. You may or may not share this with the customer, depending on the circumstances.

From here, you can prepare a draft requirements document. This document should be in table format with each row marked by an ID number, and a statement describing an expected behaviour of the system in a way that makes sense to the client and can be agreed on. Some requirements may be expressed as a user story, but if it feels contrived, then express it more plainly another way. At this stage, we're identifying what the client needs, and they may not have considered specifics on who needs to perform the action, what steps make up the action, or the precise outcomes. We will revisit these details in later iterations, after the analysis and design steps.

Inputs:

• Project brief document

• Business process and/or activity diagrams

Activities

• Customer meeting

Outcomes:

• Project narrative document

• Draft requirements document

Analysis

The analysis step is the most crucial step of a software project. Although the development phase will be iterative and allow variation, you will now decide on core data structures and behaviours that will provide the foundation for future work. It will be hard to evolve some elements decided during the initial anaylis.

In analysis, we're looking to transform requirements into a high-level specification of what the solution will actually do. We want to identify key entities and behaviours of the system. The process begins by literally collating the nouns and verbs used in the requirements document, and resolving any conflicting, ambiguous, redundant, or incomplete language found. Place the nouns in a diagram, and organise them by their relationship. Separately, maintain a list of actions that must be performed on the data. Be as complete as possible, and revise each requirement to ensure each is achievable with the initial design. It will take iteration, and probably questions of the client to make clarifications.

These two documents will become the Bounded Context diagram, and the Behaviours table, respectively. It's helpful to prepare use cases of the most complex behaviours, with sample data and interactions. This will help confirm the initial design isn't over-simplified.

Inputs

• Requirements document

Activities

• Domain and behaviour design

• Use case validation

Outcomes:

• Domain diagrams: Bounded Contexts and Ubiquitous Language

• Behaviours document

• Worked use case examples

Design

.................... TODO ..................

Outcomes:

• Data Design

• Behaviour Design

• API Design

• Statement of Work

• UI Storyboard

User Experience

At this stage, the client you may be wondering what the solution will look like. There are different ways to approach this, and I believe the right approach depends on the solution under development. Where the visual appeal of the system is important to project outcomes (such as consumer facing products that rely on customer conversion), you will want a professional product designer to prepare the storyboard and visual language before development begins.

For other projects, such as administrative and automation tools used by office workers, a basic storyboard that adheres to standard UX conventions and themes will be sufficient. A visual uplift by a professional designer can be done later in the project, possibly post-launch, and be built within the constraints of the initial design.

In both cases, the objective is the same - a detailed description of interactive journeys that users can perform, and a visual theme to be used across the system.

Irrespective of when and by whom, the starting process is similar. Begin with a navigational map of the most obvious screens, and build a low-fidelity or no-fidelity wireframe of each screen. If possible, select a design like (eg. Material) and design screens according to that standard. Maintain a mapping of each element to its originating requirement, and note where user access permissions may be required.

Evolve the storyboard into an interactive demo, and prepare a demonstration session with the client. It's best to be very complete before facing the client, to avoid uncessary diversion into matters that have already been decided. By meeting with the client, you're looking for clarifications, corrections, and potentially changed requirements.

The high-resolution designs can now be prepared. Professional designers would share design documents that specify pages (eg. Fiddler), component libraries (eg. Zepplin), mood boards, and the like.