Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Are the included and extending use cases make sense?
Basically yes, depending on what you are willing to achieve.
Include simply means that the included use case cannot exist on it's own and needs to by part of the use case, for which it is included and at the same time the basis use case won't be complete without the successful included use case.
This translated for your use case scenario will mean:
In order the user (write a name for the actor) to log in, he has to enter his User id, enter his password, the system has to parse the id and the password and display the main screen.
Extends can optionally add some other steps to the main functionality, in this case to the log in, which means that it's optional to display an incorrect log in screen (somehow verbose in your scenario). This will also mean that Display Login screen is also optional, which IMO is not the case and it has to be included in the main use case, but this is relative to what you are willing to achieve.
Advice: Learn the exact UML specification. You need to write the name of the actors, to write down <<include>> and <<extend>> and to define a system. I will suggest you to use an UML editor instead of Paint or something similar. Check What's the best UML diagramming tool?
You mixed usecase (Login) and actions of login process in one diagram.
Remove all usecases except for Login, and add activity diagram to desribe scenarion of login process.
If you create use cases at the granularity you are proposing, you will probably die under the weight of the documentation you will produce.
Here you have only one use case: Login.
In that use case you have different parts, and among those, the usual scenario steps, where you will find, for example:
1.Enter user id
2. Enter password
3. ...
you also have a section named Exception scenarios, where you will find, for example, the Failed Login details (error message, behaviour, ...).
An example of use case inclusion would be Modify Account, which would include your Login use case, meaning you cannot modify your account without login in.
An example of use case extension would be specifying different method of login in (OTP, digital signature, etc) which would all extends the Login use case.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am currently working for a company writing use cases. They have a template which mixes them with data dictionaries. I've never seen this kind of template. I searched the web looking for answers. I am wondering if this is a correct practice/method. If it is, does this template have an specific name? They are calling it use case template, I do think is wrong to call it that way.
This is an example:
Note: This template has a valid use case written above of it (not shown in here).
Step: 1
Actor: Application
Action:
Display login page
Login page section has the following fields:
- Username
- Password
- Submit button
Here's the description of the fields for this section:
- Username - textbox field, required, no default value, allow 10 character maximum
- Password - textbox field, required, no default value, allow alphanumeric characters, allow a maximum of 30 characters
Step: 2
Actor: User
Action:
User enters username & password
User hits submit button
Step: 3
Actor: Application
Action:
The app allows access to the page.
This is common practice. I don't know if he's the inventor, but Alistair Cockburn provides such templates along with rules how to fill them in.
However, for the methodological approach and much of the background info needed in use case synthesis I always recommend Bittner/Spence. (Note: there is a Word-version of this book when you google for it. I have not idea now this infringes copyrights, but the money for the book is worth it.)
Yes, I've seen this before, but it is not common practice to specify the data requirements in such detail in the use case scenario. In fact, in your example, they are even trying to describe the user interface details in words.
I would recommend, like you expect, to have a separate data model (which is a bit more than just a data dictionary) and specify the data requirements over there. For the user interface, it would be better to create a prototype or wireframe. Too often, IT departments tend to create their own methodologies instead of buying a good book.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm developing a restful API using NodeJS. To give you a little more insight in my application:
My application has surveys. A survey contains questions which in their turn has choices.
To add a question, you need to provide the id of the survey in the body of the post. To add an option, you need to provide the id of the question.
Now for the API routes. What would be better:
Option 1
/api/departments
/api/surveys
/api/questions
/api/choices
Option 2
/api/departments
/api/departments/department_id/surveys
/api/departments/department_id/surveys/survey_id/questions
/api/departments/department_id/surveys/survey_id/questions/question_id/options
The last one seems more logical because I don't need to provide the id of the parent in the body of the post.
What is best practice to use as endpoints?
I don't think there's a "best practice" between the two; rather, it's about having the interface that makes the most sense for your application. #2 makes the most sense if you're typically going to access the surveys on a per-department basis, and also makes sense in terms of accessing questions on a per-survey basis. If you wanted to eliminate the per-department part, you'd do something that's kind of a mix of the above:
/api/departments
/api/surveys
/api/surveys/survey_id/questions
/api/surveys/survey_id/questions/question_id/options
If you DO want to go by per-department, I'd change #2 so that instead of /api/departments/surveys one would access /api/departments/department_id/surveys ...
But without knowing more about the application, it's difficult to know what the best answer is.
Do surveys contain anything besides questions? do questions contain anything besides choices? The reason I ask is that if the answer to both is no then I'd actually prefer something like this:
/api/departments/ # returns a list of departments
/api/departments/<survey-id>/ # returns a list of questions
/api/departments/<survey-id>/<question-id>/ # returns a list of choices
/api/departments/<survey-id>/<question-id>/<choice-id> # returns a list of options
or something to that effect. Basically, I like to keep the concept of "containers" and "data" rigid. I like to think of it like a file system.
So if the concept ends in an "s", it's a container (and I'd like the route to end with a "/" to indicate that it acts like a folder, but that's a nit).
Any access to "/" results in the element at that index, which of course can be another container. Similar to directory structure in a file system. For example, if I were to lay these out in a file system, I might come up with something like this:
+ /api/departments/
|-----------------/human-resources/
|---------------/survery-10/
|----------/choice-10
The choice depends on whether resources are owned or shared by higher-level resources; whether you want cascading delete or not. If owned (with cascading delete), choose option 2 and if shared, choose option 1.
If a survey is deleted, I guess you want to delete all questions and options with it (cascading delete). This matches well with option 2, because if you delete resource /api/departments/departmentid/surveys/surveyid, you naturally also delete all subresources /api/departments/departmentid/surveys/surveyid/questions/....
On the other hand, if you want the option to share questions among multiple surveys and share surveys among multiple departments, then option 1 is better.
Of course, you can also have a mix of option 1 and option 2, if some resource types are owned and others are shared.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm designing a REST API and trying to decide which is the more correct way of returning a single resource:
/resource/{id}
or
/resource/{name}
The ID would be immutable, so I'm thinking that it would be better to select by it, but name would be more friendly looking. What is the best practice? I've seen both used before "in the wild".
Basically REST is built on top of unique IDs, thus:
GET /resources/{id}/
should be used. However, there's nothing that prevents you from making name field unique (now it behaves as plain old ID) and build REST on top of this unique ID.
If this is not what you need and name cannot be made unique, then another option is to implement filtering via name:
GET /resources?name=<SOME_NAME>
It also should be resources (plural) since it indicates that there's a collection under the hood.
Whether using name instead is practical comes down to your business case.
Will 'name' always be unique? Or will the application deal with there being more than one occurrence?
Are 'pretty' URLs important? In most applications I've worked on, querying uses unique IDs which are never exposed to the end-user, as they have no business meaning whatsoever. They are in effect surrogate primary keys.
/resource/{id} is more technically correct, but if it were me, I'd allow both. Assuming names can't contain ONLY numbers, and ids can ONLY be numbers, you could easily detect which was supplied and allow for either to be used. ;)
This is good question .. it depends on business case example if api is used through cli like docker then you might want to use user friendly ids like name
But as soon as it become part of URL it has limitations like ASCII (to avoid url encoding or loss of readability ) char only and some defined length like 128 chars etc.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
When creating a url, I am thinking of these ways of how to do that
example.com/restaurants-in-new-york
example.com/restaurants/in-new-york
example.com/restaurants/in/new-york
So, the question is how Google considers this ? If I search restaurants in new york to which type the preference is given.
Which will have higher ranking ?
They'll all probably have the exact same ranking, no matter what. More important: Don't screw up real users when doing SEO.
Simple reasons:
You might do everything for nothing (i.e. no or no significant change).
Talking URLs are for users to know what content they can expect. They're not for search engines. if you optimize your overall appearance just for a high search engine ranking, even if people won't want your page contents, you might profit off this at first, but they won't return.
When using path separators (/) in your URL, expect users to use these. If they can't use them, you generate a bad user experience and they might rather leave your page and look elsewhere for what they're using.
Similar reason: Only use path separators if there's a real reason for them, for example, if they're some logical grouping. In your example above, the second and third variation would be bad, because the separation doesn't make any sense at all.
How I'd do it:
If we're talking about a single blog post or something like that, don't use any path separators at all: example.com/restaurants-in-new-york. That's it. Don't touch it or change it.
If we're talking about some listing, you can provide the user hints on how to quickly change their actual query or results. Here I'd use something like example.com/restaurants/new-york.
I hope you understand what my intention here is. Let's assume the user now wants to know what restaurants are there in Chicago. He won't have to navigate or look for some link. He could just edit the URL: example.com/restaurants/chicago. There he is. Good user experience. If you look at your third example, you've got that unnecessary filler in: It doesn't serve any purpose at all (hint: Google most likely ignores such fillers anyway).
TL;DR: Don't optimize for Google or any other search engine. Optimize for your users. Modern search engines are built to see pages similar to users. You can have the prettiest key words in your URLs, yet they won't help you at all if they're strictly confusing or obviously just made for SEO.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've just finished the implementation of my software system and now I have to document whether it has satisfied its requirements. What sort of information should I include and how should I lay it out?
My initial functional and non-functional requirements was in a two-column table and looked something like this:
FN-01 The system should allow users
to send private messages to each
other.
NFN-03 The setup/configuration
form should contain sensible default
values for most fields.
I would use the requirement numbering scheme already in place rather than creating a new one. I would document the following items for each requirement:
Requirement Status: This can be phrased in many different ways but you are tyring to communicate if the requirement was completed as listed, completed in a modified variant of what was listed or was simply not able to be completed at all.
Requirement Comment: Describes the previously listed requirement status. This is the "why" that will explain those items that were not able to fully meet the requirements.
Date completed: This is mostly for future product planning but also servers as a historical reference.
A couple of other points to remember:
Requirements may be reviewed by the customer, especially if the customer was the source of the requirements. Hence, this document needs to be as accurate and as informative as possible. (It's also another reason you don't change the requirement numbering scheme unless you have to.)
Your testing department (assuming you have one) should be using these documents for their test planning and they need to know what requirments were met, which ones weren't and most importantly which ones changed and how.
Lastly, unless you're putting on a dog and pony show for someone you shouldn't need screenshots as part of requirement documentation. You also shouldn't need to provide "proof" of completion. The testing department will do that for you.
there are some techniques to convert your requirements into test cases.
But those depend on how your requirements are documented.
If you already have made a scenario based requirements analysis then it would be very easy: Just create a sequence diagram for every path of your scenario, write/do a test -> done.
Besides the documentation created that way should also impress your lecturer.
If you don't have scenarios, you should create some out of your use cases.
The downside here is that it is very work intensive and should only be used in cases that justify its use (a thesis for example ;))
List, one by one, the requirements numbers with the requirements line, then text and/or screenshots proving it does so.
Have the requirement number on the left in bold, then have the requirement text tabbed in and italicized. Align the proof text/screenshots with the requirement text, leaving the left column clear for just the requirement numbers. EG:
REQ-1 italicized requirement text
text discussing how the software has
fulfilled the requirements, possibly
with a picture:
-----------------------
| |
| |
| |
| |
| |
-----------------------
REQ-2 italicized requirement text
etc...
You should group into chapters or sections based upon logical program areas, and start the section or chapter with a blurb about how the whole program area meets the requirements (be general
I would keep it simple and add the following columns:
Delivery Satisfied requirement - with a drop down list containing Yes, No, Open
Comment - any comment regarding the delivery, such as 'need to define message size', 'Does not fully satisfy in the layout of the message, but accepted by the client', etc.
Date completed - when the change was delivered
Date satisfied - when the change was accepted
With the use of requirement ID's, I'm assuming they point back to the docs containing more detailed info including layouts, screen shots, etc.
We would normally have a test plan in place in which each item can be ticked-off if satisfactory. The plan would be based on the original requirements (functional or non-functional) for example:
Requirement: The users account should be locked after three attempts to login with an incorrect password.
Test: Attempt to login more than three times with an incorrect password. Is the user account now locked?
We would do this for each requirement and re-run the plans for each Release Candidate. Some of the tests are automated but we do have the luxuary of a test team to perform manual testing as well!
Based on the results of running these test plans and User Acceptance Testing we would sign-off the RC as correct and fit for release.
Note that sometimes we will sign-off for release even if some items in the test plan do not pass, it all depends on the nature of the items!
The formal way to validate requirements is with testing - usually acceptance testing.
The idea is: for every requirement, there should be one or more tests that validate the requirement. In a formal development situation, the customer would sign off on the acceptance tests at the same time they sign off on the requirements.
Then, when the product is complete, you present the results of the acceptance tests and the customer reviews them before accepting the final product.
If you have requirements that cannot be tested, then they probably are badly written.
e.g. don't say "loading files shall be fast", say "an file of size X shall be loaded in not more than Y milliseconds on hardware of Z" or something like that.