I am curious because it seems like everyone has different opinions on the matter. When creating an SRS document, do you need both use cases and functional requirements or just one since use functional requirements expand on use cases?
... do you need both use cases and functional requirements or just one ...
The difference is only in approach if one were to close-read the primary authors of these techniques.
Use cases approach is considered a more efficient means of collecting essential requirements, whereas functional requirements approach ensures a complete specification that can then filter out redundancies, overlaps, and unwanted features.
Use cases approach takes into account at the outset external actors (users, processes, agents, etc.) and how they interface with the system, whereas the functional requirements approach the problem from a solution angle (how can we employ this feature to solve our problem?)
Use cases capture actors, users, methods, domain knowledge, unique techniques, etc. Use cases can lead to complete packaged solutions. Functional approach capture product categories, product variants, market differentiations. Functional approach can help develop finely tuned release strategies where functionality is developed and layered over previous releases.
Another way to describe is that use cases is more an user-oriented spec and functional approach is a developer spec. From a language and communication perspective, it is said that use cases approach leads to easier to understand documentation that is already cast in the end-users' language idioms. On the other hand, functional approach is what makes the system complete and integrated whole.
In modern SRS, both perspectives are essential for a complete, useful system. Ideally, one has to map to the other. Benefits of both approaches cannot be discounted no matter where one starts the process.
Another way to describe is that use cases is more an user-oriented spec and functional approach is a developer spec.
, think that's enough to describe it. –
Hyacinthe If you need to use both (because the system is large or complicated) keep Functional spec higher level than Use-cases. If you define Functional spec (e.g. BFD or other notation) you can then usefully add either Process models, Story Mapping, leveled DFDs or Use-cases at lower levels depending on the view you're after. DFDs and Entity Model cross-check each other.
It's fully up to you to decide whether you want the one or the other or both.
Functional requirements are a set of requirements, mostly in text form that defines the system functionality being developed. Use case diagram is requirements elicitation of a software system. Both can be used and there are clear advantages in doing so. The functional requirements can easily be used as unit test cases, whereas the use cases can be used for user acceptance and integration tests. Depending on the level of detail use case diagrams can also be used for unit tests.
From a historical perspective functional requirements was used before UML became a standard in object oriented software development. Hence these days use cases are the preferred method for capturing a systems functional requirements, if both are not to be used.
The main difference is that use case diagrams are a graphical representation of the systems requirements, whereas functional requirements are in text form. Use cases can also have text but the main focus is on the diagram itself, whereas in functional requirements the focus is on the written text.
© 2022 - 2024 — McMap. All rights reserved.