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 am new to writing use cases.I heard that Use cases are non-technical expressions .
I have the following task for which i have to write Use case.
(I reduced the requirement for your understanding)
Registered Customer of ABC company logged in to the system with credentials to retrieve
the complete Address of particular service provider.He searches the service provider on TextBox.The System communcates with database and displays the result on monitor.
I am technical guy,
I have to write use case to explain the behavior of the system to the client.
I have written Use case as follows :
Use case Name: Address Locating System
Primary Actor: Customer
Stakeholder: ABC Company
Precondition: Customer Successfully Logged in to the system
Success Scenarios:
Customer Enter the search term in the box provided.
System searches the search terms for matches.
System Supplies the address to the Customer.
Extension Point: Client is informed when no successful match
Post condition: None
Questions.
Is the Use Case described above, correct?
Do really tech people need to write Use cases?
Whenever I need to write a Use Case, I pick up my copy of UML Distilled and use its suggested format. There are variations in the formats, so this isn't the only way. In any case it's a good reference to have on your desk. You might also check out Writing Effective Use Cases; I haven't read that one, though.
If you'd like a free example, see:
http://ontolog.cim3.net/cgi-bin/wiki.pl?UseCasesMartinFowlerSimpleTextExample
I might avoid the "in the box provided" bit - that's an implementation detail that might change. I might also change 2 to just "System searches for matches."
And yes, technical people do need to write Use Cases readable by non-technical domain experts.
I would say that this is your use case:
Registered Customer of ABC company
logged in to the system with
credentials to retrieve the complete
Address of particular service
provider.He searches the service
provider on TextBox.The System
communcates with database and displays
the result on monitor.
There is no need to do all the formatting, special headings, numbering etc. Give it a title and you are done. For presentation to a client,
I'd use use case diagrams, and not show even this amount of detail unless asked.
Related
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 2 years ago.
Improve this question
I am currently developing a Website which allows users to create Blog-posts and was wondering whether I should allow them to delete their Posts from the Database. On one hand, they could be writing illegal stuff and delete it shortly afterwards, which would make it impossible to follow up on this issue afterwards, on the other I might have to provide such a feature. I was thinking about implementing a "soft-deletion", which allows users to mark a posts as deleted and deleting all marked posts after a couple of weeks.
My question now is whether this approach would be legal, especially considering the GDPR. How would you go about it?
I'm aware that I might be in the wrong community (Stackoverflow) here and am open for suggestions for other forums.
Edit
The website is hosted and has its Guests mostly in Germany. Does anybody know about the lokal laws and how they play for this problem?
GDPR is only concerned with personal data, which is data connected with people, so if I write a blog post that doesn't contain any personal data, GDPR simply doesn't enter into it except for identifying me as its author. With that link removed, it's just regular data.
If you consider the blog post along with its author identification as a single item, then it would count as personal data, and they could ask for it to be deleted. There is some wiggle room for practicality here though. You can reasonably do as you suggest and soft delete now and really delete later, but you should make it clear in your privacy policy that that is what you are going to do. You could cite a reasonable case of legitimate interest to allow for letting data fall off the end of backup cycles, allowing a grace period for them to change their mind, accidental deletion, and abuse.
A separate issue is copyright, which remains with the author regardless of whether they are credited (unless for example they write it under contract to you and waived their rights or assigned ownership to you).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Just found about this new regulation, it will be law in 2018 and affects anybody who stores data about EU citizens, that can be used to identify a person. More detail here.
I have a page that doesn't store names and exact addresses but it stores birth dates and country/city as location and uses these two to provide a service (which is the core service, so I can't just stop collecting these data).
From what I understand I have to take some action to ensure compliance with GDPR, but I haven't found reasonable explanations what that means. There is a dozen articles that rephrase paragraphs of GDPR, that is not helping at all.
I don't mind full deletion, explaing what data I store to the users and simmilar points ... What I am mostly worried about is the part about anonymizing data so in case of a breach they can not be used to identify a person. How am I supposed to do that? If I store an email address used to verify an user account and tie birth date and location data via PK to that verified email, they are no longer anonymous ... and they can't be, right?
Any thought about practical solutions to become GDPR compliant?
Ultimately, in the UK, the GDPR will be enforced by the ICO - Information Commissioners Office. Whilst some of the regulation is quite clear cut, the articles relating to anonymisation are open to interpretation and we'll probably only fully understand how the line is drawn once the ICO has enforced a case relating to it. Having said that there is a bunch of good info on their site.
Their is also a group of academics in the UK advising both the ICO and businesses (for free) about anonymisation. They're called the UK Anonymisation Network - UKAN. I've had a web meeting with them - they're awesome.
It is unlikely you will have to anonymise your data if you use standard encryption to store your data at rest. Anonymisation may come in handy if you are sharing any of that data with third parties. In the event of a breach on their system, you can demonstrate you have taken as many steps as possible to mitigate your risk.
I agree with the above - GDPR is a great thing for privacy rights and data control - I also agree that there are a million sites out there just rephrasing gdpr!
In terms of practical steps, more guidance is going to be released by the ICO this month. But it makes sense to begin by mapping out what user data you process, whether the reasons for this are justified and whether there you have asked for EXPLICIT permission to use that data in that way. Further to this you should think about how you can delete data if it's requested.
There are services that will keep independent record of opt ins and alert you to data vulnerabilities. Anonomisation works in some cases, in others, if you have permission, then all you need is process to delete and an audit trail.
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 5 years ago.
Improve this question
I need to add an item to our product backlog list that has no (perceived) value to the users.
Context: every week we need to parse and import a TXT file our system. Now the provider decided to change the format to XML, so we need to rewrite the parsing engine.
In the end the user won't see any benefit as he'll keep getting his new data, but we still have to do this to keep importing the data.
How to add an item like this to the product backlog list?
What happens if you don't make the change? Is there value to the user in preventing that from happening? If the answer is yes, I'd recommend tying your business value statement to that. Then, you can write a typical user story with business value and treat it like any other PBI.
It has no value to the user, but it has value to your company.
As company X I want to be able to support the new XML format so that I can keep importing data from provider Y.
How does that sound like? Not all stories necessarily evolve around the end user.
Note: technical stories and technical improvement stories are not a good practice and they should avoided. Why? Because you can't prioritize them correctly as they have no estimable value.
The correct way to do tech stories is to include them in the definition of done. For example: decide that every new story played is only complete once database access is via Dapper and not L2S. This is a viable DoD definition and makes sure you can evolve your system appropriately.
We typically just add it as a "technical improvement" and give it a priority that we think fits. If the user asks you about it, you just explain them high level what the change does and why it's needed.
Don't forget that your application will most likely start failing in the future if you don't make the change. Just tell them that, and let them decide whether they want that or not.
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
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
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 3 years ago.
Improve this question
Most of you certainly use some kind of bugtracker. Maybe internally only, once a customer files a bug via email or phone you add a new ticket by yourself. Sometimes weekly project meetings can be great source of new tickets coming preferably in flavors of excel sheets that the PM on the other side of the table loves to maintain and chase after you.
The more advanced (and transparent) version: Allow the customer to file (and see the progress of) his bugs directly into you bugtracker. Systems like JIRA allow you to use profiles to have certain access rights, etc.
But now the question: The bug raised by a user not necessary translates into 1 bug in a specific module/method/EJB/class. The version of the (your) web application he uses does not translate into the version of the class that is causing the error. How you maintain the internal part of the ticket with all the nasty techy details and the same time the make-the-user-feel-good ticket (need more info, accepted, in progress,..) ? Creating 2 tickets for internal and external ? Link them ?
Any smart recipes to share ?
Separate your bug system from your customer support tracking system, and allow links between them.
Bugs can refer to zero, one or more customer support tickets.
Customer support tickets may refer to zero bugs (e.g. the customer's problem has nothing to do with your software), one bug (in case it's really a problem in your software) or more than one bug (shit happens).
Make queries like:
Which customers are waiting for a solution of bug X
Which customers are waiting on open critical bugs
Which bugs were already encountered by user Y
...
You will also notice that each database will have its own 'speed'. In my situation I have about 4 times more customer support calls than real bugs.
Most sensible way is to have two systems, or an alterantive mechanism for end users to submit bugs (via email). The main problem is not so much that a bug not necessarily translates into one method in a class, but mostly that if you have more than a handfull of users, peopel wont read existing bugs and think further than "button does not work".
If you isolate the real incident system (make it public, but read only), your staff can screen incoming bugs, make sur ethey are reproducable and have repro cases, check against existin bugs and in general have a clear bug once you enter it, and not soe hard to understand mess that may or may not ven make sense and be yet another entry of the same bug entered another 30 times already.
Each comment in JIRA has a "Viewable By" field that allows you to set the Group or Project Role to whom the comment is visible. You could use that to hide the "nasty techy details".
Alternatively you're probably on the right track when you say create two issues and link them. This has the added benefit of hiding your internal workflow from the customer.
One system for both (external) Help Desk and (internal) Issue Tracking. As long as you have complete control over visibility of tickets/issues, and can link between external/internal items, then this is no big deal.
Read more:
http://countersoft.com/downloads/whitepapers/Implementing_an_Issue_Management_Platform.pdf