What are the best practices for using the Use Case method to document system requirements?

Use cases help with connecting the individual system functional requirements to tell the story on how the customer/actors are expected to interact with the system and use it. Some of the benefits I vouch for are the following: - ensures usability is factored into the requirements - identify error scenarios for each step leading to a stable solution - identify integration points between systems and resulting latencies, leading to additional KPI definitions - identify and fix gaps in requirements - provide a clear idea on how to validate the system leading to fewer bugs in production All of the above become even more prominent when the requirements span several systems, each with its own lifecycle and rate of evolution

Ensure you sufficiently define your system first as without this how can you define the actors and the goals. Once you have this you have a better idea of who may act upon it and who may be acted upon by it, along with what goals may be associated with it.

...writeup must be Technology-agnostic and OPERATIONAL Goal-oriented. In my experience Domain experts do a better write-up compared to Programmers/Developers

Learn the best practices for using the use case method to document system requirements in systems engineering, such as defining actors and goals, using templates and diagrams, writing from user's perspective, and validating and verifying use cases.

The System requirement gathering is the first step. Once you are clear about the system requirements, you know the functionalities and how they are going to interact with the external entities (actors). Then we can define the use cases which represent various functionalities delivered by the system. The use case specification should be detailed enough ( may be detailed through written statements or activity diagrams) for the software engineer to start his work.

Use models (diagrams) to facilitate the requirements analysis process. Modelling provides a hierarchical framework that represents the System from various perspectives, which is crucial for discovering and defining requirements in a structured way. Use UML, SysML, and frameworks like NAF or Arcadia. With a modelling approach, each Use Case can be elaborated upon, by tracing down to more detailed diagrams like Activity or Sequence diagrams. This provides a strong basis for defining Stakeholder and System Requirements. (See example below).

Functional engineering relies on use cases as its foundational inputs. The process yields engineering design requirements as its ultimate outcome. Take, for instance, the use case of a vessel for drinking coffee. Upon comprehending the vessel's function, various boundary conditions come into play, encompassing factors like the type of material capable of withstanding a range of temperatures, tensile strength, abrasion resistance, size, volume, and more. Each property selected becomes an inherent use case, defining every aspect of usage. Often, these considerations are recognized either upon product failure or during the alpha prototype stage. The insights from such experiences lead Beta prototype, which closely aligns with production proto.

It's important to concentrate on completeness and clarity while utilising the use case method to establish system requirements. After determining the important players and how they engage with the system, develop succinct, informative use case templates that detail each situation. To graphically depict the links between actors, use cases, and system components, employ diagrams like UML diagrams. Maintain uniformity throughout templates and diagrams, and periodically check and update them to take into account modifications to system functionality or requirements. By adhering to these best practices, you'll facilitate stakeholder comprehension of the system and improve communication.

The problem of conventional technical requirements lists is, that they go easily to deep into technical/technological implementation details which is not good for the system as it already predefines or influences the entire rest of the system and creates dependencies that should not be there. The use of model based tools helps to start from abstraction level and then go down step by step into the real technical environment with clear and visible interfaces/dependencies on each level. I call it the "rubberband method".

For effective system requirements with Use Cases: 1. Define actors & goals: Who interacts (actors) and what do they want (goals)? 2. Clarity & consistency: Use templates & diagrams for clear use cases. 3. Focus on users: Write from their perspective, reflecting their actions. 4. Validate & verify: Gather feedback to ensure accuracy and completeness.

User Requirements (a component of Stakeholder Requirements in ISO 15288) capture the behaviours the System must exhibit from a *User's* perspective to fulfill each use case. System Requirements then articulate the functions, attributes, and constraints from the *System's* perspective to fulfill each User Requirement, tracing all the way back to Use Cases. An example of a Use Case for a driver (the Actor) of an automobile (the System) can be captured as 'Travel by road'. Downstream models can be used to represent User Requirements for controlling speed and direction. System Requirements further downstream can then define what the System must do, and how well, in response to user inputs to control speed and direction.

What is typically forgotten: engineers develop a product for engineers. Engineers should be responsible only for the technical implementation and validation but not for writing use cases. Use case definition (as well as misuse case definition) should be defined by users. A user can also be a whole market. If the system engineer knows nothing about the user behaviour or expectation of another market in the world, then the output must be insufficient! All technical things are seen, understood and used very differently in different markets. Only a model based tool can provide templates with use cases for different markets.

I believe every product needs three types of documentation. Technical documentation used by implementers and architects to record decisions, designs, code documentation, proof of concepts and workflows. Operational documentation used by operators during incidents, SLA calls, service requests and configuration changes. Customer documentation used by product target to improve adoption and allow learning what are the features, pros and cons and advantages to use our product.

Don’t put everything on the same diagram, rather create one diagram one view for each idea you want to present. These views should be drawn from an actor/stakeholder perspective: so that actor is related to ALL use cases in that diagram. Then that actor won’t appear explicitly in that diagram. Oh, and keep it readable: use the 7+/-2 rule: to the number of use cases you add on one diagram. If more are needed create separate views to transmit different ideas.

One thing I've found it useful, is to define top level customer required functions in use cases. If you can state and model other contexts in comparison to "in operation", you are at a pretty good spot!

Start by not thinking of requirements process as ‘document’ - more ‘elicit, understand and share’ Use cases belong clearly in first two of these - and only need to be ‘documented’ as rationale for requirements Stakeholders famous for not being able to state everything they need. So use cases help understand what use system put to - which will give you some of the functions, sone idea of how well and clarity of context But use cases alone not enough - may not give all functions, and certainly not all attribute (reliability, cost) constraints You have to analyse But use cases key tool in requirement elicitation tool box

Identify Misuse Cases to identify and mitigate ‘reasonable foreseeable misuse’ - a legal requirement. Also identify Misuse Cases to identify potential safety requirements and which can then be developed using Fault Tree Analysis.

Use cases should be living things and trace from the requirements based on them. Get in the habit of not just reviewing use cases, but reviewing more detailed scenarios refining those use cases. Modeling use cases and scenarios and then simulating them during reviews is a great way to get some early validation. When you do functional requirements reviews, pull those use cases and scenarios out again for context. Having identified not just stakeholders but also their concerns will help you construct appropriate views tailored to those stakeholders, which goes a long way in SETRs.

Use cases are not meant to be kept on the shelf when done, nor to be perfect. Put them in front of your stakeholders and discuss them. That’s how you validate and elicit requirements. Then don’t have to be perfect, don’t spend too much time to make them petty . I’d go so far to suggest to keep them deliberately incomplete. So they generate conversation and you get feedback, people’s contribution. Use cases are not so much an engineering artefact as they are a means for communication, an aid/tool to help identifying stakeholder requirements.

With most validation processes, reports document and keep track of most details of any report, both on the vendor side and the client side. The content of the reports determine the time-line of the details of most reports. Compliance and completion are the icing on the cake for most realistic projects.

Use cases are not requirements, they are a really good SOURCE of requirements - use the use cases to identify the requirements, and ideally retain traceability back to the use cases.

Here are some tips to help you make the most out of your use case documentation: 1. Identify actors 2. Write concise and clear use case names 3. Use standard templates 4. Focus on user goals 5. Include all relevant scenarios 6. Keep it simple and precise 7. Review and validate 8. Maintain traceability 9. Consider using visual aids 10. Update documentation as needed

A thinly covered risk I have seen with a collection of requirements: the creator(s) has missed something and is no longer available by the time verification and validation is being implemented. Who is responsible now? Refactoring at late dates is sometimes discouraged. Yeah, it is expensive. I recommend a closer connection to the V&V planners at the start. Some clever collaborators can determine ways to “bring the future forward”. Digital transformations of requirements into collections of representations that can have the gaps highlighted through digital and human reviews would be one way.

Case methods..my friends..requires two critical factors....REQUIREMENTS AND SPECIFICATIONS....nothing is perfect in our world...supporting testing Engineering the last 40 years...i can say that....the unaccountable variables..affecting the performance of a new system...device or software product...as of its use from external operators..and the complexity of its performance..requires above all scientific and technological expertise..fantasy..technological innovation..and mainly able to think and design out of the box...

Start with the common use cases and with the most important ones. Dont try to sketch all the possible forks of the use case, instead describe only the main successful forks, and leave place for commenting on the main "If - else" scenarios. Describe in details, in a different use case also the negative scenarios of the use case, e.g. Side A sends a connection request, no response from side B. Or nack response. Etc.