Analysis and Design Experience

Analysis and Design Trends

I have been actively engaged in the practices of identifying user requirements and of designing computer-based systems solutions for more than 30 years. Over that period, I have practiced systems analysis and design using a series of methodological approaches:

  • Classic analysis and design with narrative functional specifications and narrative technical specifications
  • Structured analysis and design with DFDs, mini-specs, structure-charts, etc.
  • Prototyping with limited formal analysis and design documents
  • Object-Oriented analysis and design with use cases, UML diagrams, etc.
  • Agile development approaches using user stories

Over this period of practice, certain aspects of analysis and design have certainly changed:

  • Computer-based solutions are now used to solve a significantly larger number of user problems in our everyday personal and professional lives.
  • User expectations regarding the functionality delivered by computer-based solutions have risen substantially.
  • User expectations regarding the usability of computer-based systems have risen even further.
  • Analysis and design techniques that focus the effort of development teams on use and usability (like use cases, user stories, wireframing, and storyboarding) have become an important component of the analysis and design process.
  • Analysis and design documents that were once predominantly expressed as free-form prose have increasingly been replaced with documents based on standard diagramming languages (like UML or DFDs) and highly-stylized prose.
  • The use of the object-oriented paradigm to describe both problems and solutions has gained a significant following among practitioners.
  • Agile approaches to systems development, that combine analysis and design with construction in the same project phase, have gained a significant following among practitioners.
  • The use of computer-based tools for all aspects of analysis and design has become so commonplace that what were once called CASE tools (computer-aided systems engineering tools) are now just the everyday tools of the trade.
  • The practice of business analysis has come to be distinguished from systems analysis as a means of identifying a proper role for non-technicians as they participate in the analysis and design process, and as a means of expressing a continuity between activities traditionally described as management consulting with activities traditionally described as systems analysis.

By contrast, some very important aspects of analysis and design have remained the same:

  • The practice of interacting directly with users (using interviewing or JAD-like approaches) in order to understand and document their requirements is still the gold standard of requirements-related work.
  • Tools and techniques that relate the features of the system directly to its usage patterns (like use cases) and that make concrete samples of the user interface available to users sooner (like wireframes, prototypes, and iterative system deliverables) keep users engaged in the project more fully throughout its lifecycle.
  • The extent to which newer tools and techniques are adopted (or any formal techniques are employed) still varies substantially from organization to organization.
  • The exact tools and techniques employed still vary from project to project even within the same organization depending upon the individuals assigned to the project, the nature of the end product, and the sensibilities of the end users.

My Current Approach

My current approach to systems analysis and design is highly adaptable and focuses on capturing user requirements effectively and delivering the solution quickly. I believe in a sufficient amount of scoping and planning before analysis and design in order to avoid wasted effort on the part of all stakeholders. I firmly believe that we need to understand the use cases well before we begin to implement the systems components that realize those use cases. Having accomplished that, I believe in proceeding with agile approaches that favor the delivery of working code over the delivery of elaborate specifications. Consequently, I favor project approaches that mix analysis and design activity with construction activity within a controlled, iterative framework.

Nevertheless, I fully understand that I must accept my stakeholders (users, funders, analysts, designers, coders, testers, and deployers) as I find them. Consequently, I always seek to build a project plan and methodolgoical approach that best suits the people involved and the problem at hand.