-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minutes 2021-08-18 #250
Minutes 2021-08-18 #250
Conversation
These evaluations are, in my view, meant to show how the whole system is working. | ||
Unless you have a client and a server working together, we don't have a protocol. We need a system where the client can discover what the control rules are. | ||
|
||
Elf: That is UC3, would you add those concerns to every use case? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's OK for some Requirement(s) to be required by multiple Use Cases, and for one Use Case to have several Requirements. Typically, there will be some Requirements that are required by two or more Use Cases, and some that are required by only one Use Case.
Use Cases should be realistically simple (or complicated), and not leave out important elements of process just to limit the number of Requirements they have. That said, it can be helpful to start with the ultimately most simple Use Case (with few Requirements), and add complications (and Requirements) to subsequent Use Cases, until reaching the ultimately most complex Use Case with the most Requirements.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Fun picture I just found on the net
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
No description provided.