Diagrams in the Design Stage in the Lifecycle

About requirements and design

The requirements describe what is needed and expected to solve a given problem.

The design describes a possible solution to that problem.

The SRS is the System Requirement Specification. So it shall describe the problem space and not the solution.

All kind of diagrams can be used in such a document: plain old data flow diagrams, swimlane flowcharts, business process models, use-case diagrams, and even state machine diagrams AS LONG AS THEY DESCRIBE REQUIREMENTS. A typical use of a state diagram is for example to describe lifecycle requirements of some domain elements or event-related requirements.

About your questions

Q1: yes, all diagrams may be used in the SRS, but only if they are valid independently of the software that will be implemented.

Q2: I‘m not sure that I understood it well. But in principle, if there are behavioral requirements for a system that are well represented as state machine, it is not shocking to see this SM as a definition of the (required) system.

Q3: the design is about defining the solution:

• The requirements define the borders of a piece of puzzle, or the surroundings of a black box. The design shall now focus on the piece of puzzle itself, or on the internals of the black box.
• You may use similar diagramming techniques, but for different purpose.
• There is in principle no complete overlap in the content. If there is, it‘s mostly because the requirements were not real requirements but already envisaged a chosen solution. Note however that design diagrams may enrich requirement diagrams. A class diagram can for example describe requirements about domain objects and their relation (e.g a purchase order can have several items, each corresponding to a product) which are zldo useful for the design, but enriched with properties of each class, or more technical classes that contribute to the user interface or the persistence.

The risks

SRS are mostly used in specification based developments. They are suitable when the requirements are very well understood before the design and implementation starts.

There are significant risks in over-specifying such requirements, for example :

• design choices are mistakenly included in the document, closing doors to better solution alternatives.
• the old system is described, causing the new system to inherit old flaws and neglect opportunities to question the needs and do things better
• users/stakeholders do not understand and end-up agreeing on something that looks convincing but without grasping the consequences nor identifying the limit between real need and artificial requirement.

The more diagrams, the higher those risks.

This is in total contrast with more interactive and dynamic approaches where requirements are captured as user-stories or use-case slices (use case 2.0) and the initial requirement statement is reduced to core goals and a big picture that will unfold during the project, when more details are added gradually.

It's crucial to separate requirements from design.

Requirements are about what the system does, while the design is about how the system does it. You typically need some kind of requirement, whether that's a formal requirement in the sense of IEEE 830 or ISO/IEC/IEEE 29148 or an informal requirement in the sense of a representation of a stakeholder need or expectation, to perform design. That is, you need to know what the system must do to figure out how the system is going to do it.

Depending on your life cycle model, it is highly likely that you will have feedback from the design activities back into requirements activities. In iterative and incremental life cycle models, you will likely revisit all of the different activities at multiple points throughout the effort. Some requirements activities may come after design work happens. Strictly sequential work where the requirements are frozen before design and not revisited typically doesn't work out very well.

There's nothing wrong with graphical and tabular models in requirements. There's a whole book on the effective use of visual models in software requirements engineering. Among others, it includes the use of business objective models, objective chains, feature trees, organizational charts, process flows, ecosystem maps, decision trees, data flow diagrams, state diagrams, and more. I don't think that there's a comprehensive list of diagrams suitable for requirements engineering, since it depends on the context and information needs of the people performing the design and construction activities.

If you should include diagrams and what diagrams to include as part of requirements specification activities depends on the context in which you are working. If the diagram describes what the system must do or how the system must fit into an existing process or workflow, that falls into the domain of requirements engineering. In my experiences, this best aligns with software that is designed to fit into an existing business process or workflow, and understanding the workflow is important to design and construct the software effectively.

Most of the time that I've seen model checking employed (which isn't often, due to the level of detail and rigor needed) has been in design activities rather than requirements activities. However, I don't think I'd preclude the use of model checking tools in requirements engineering.