Tag Info

Hot answers tagged

34

If possible, may be spend some time to check if this defect can be reproduced by putting some sleep or block in your application code. But do not spend too much time. As this issue is due to multi-theading (and also as you observed), it's occurrence will be rare. My advice is not to sweat over this too much. Continue your work. Whenever you come across ...


20

"A bug in requirements" could refer to one or more of the following (more may exists though...): A requirement provided by the end-user that conflicts with another requirement or constraint. Example: The user wants to email all customers but does not want the system to collect customer emails. A requirement provided by the user and not flagged by the ...


17

Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time. When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this". Part of a job of a competent software developer is to help those ...


15

Recently, I had the "pleasure" of producing three separate prototype solutions for a problem our company has related to reports and presenting them to my bosses. Each had its share of advantages and disadvantages in terms of development time, performance, scalability (time between start of project and being able to begin producing reports), ability for ...


12

To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement". It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in ...


12

I'd categorize those as "implicit" requirements. Like "User must be able to log in" implies that there is the notion of a User (with an associated database table/store of some sort), some notion of a password or other credentials, and the requirement to store the user ID or some other token in the session. This further implied (to me, anyway) that there ...


11

It's not about using acronyms at all. It's about perception. If you ask a business to rank everything 1, 2, 3, 4 or High, Medium, Low then everything becomes a high priority. You're not really explaining, in those systems, why you're asking. If you ask businesses to rank things as must have, should have, could have, would have, then you are simultaneously ...


11

functional requirements What the system is supposed to do, process orders, send bills, regulate the temperature etc. etc. operational requirements These are about how to run the system. Logging, startup/shutdown controls, monitoring, resource consumption, back up, availability etc.etc. technical requirements These are about how the system is ...


10

So, from your more or less clarifying comments, I got it this way: You are sure there is only a simple additional exception handling missing, and you know already which code line in the lib is problematic and how the lib could be fixed. Why then don't you just add the few missing lines of code to the lib by yourself, ask the team kindly to test the lib ...


10

Infrastructure details are called "non-functional" requirements. It's a weird term describing those requirements that are not visible to the end-user, but are still necessary for the application to function properly. However, The application shall provide a mechanism for allowing the user to change his password and The user session must time ...


7

Get the specifications! If that is not possible, reject the task! It is your responsibility as a programmer to force the person asking you to do this job to provide you with sufficient information. This is not only in your best interest but also in the best interest of said person. Otherwise you risk that your client will be unhappy of the results, and ...


7

Ron Jeffries wrote a long time ago about the 3Cs of user stories (http://xprogramming.com/articles/expcardconversationconfirmation/) with the emphasis on a card (short description), conversation between the customers and the delivery team once a user story becomes actionable, and the agreed confirmation of a story after that conversation. essentially, ...


7

I think that the closest thing that I can think of would be a "derived requirement". These are requirements that are generated by the development team, based on a number of sources such as regulatory agencies, corporate guidelines, and past experiences on similar projects. However, even after you derive additional requirements from the customer/user ...


7

You bring up an interesting point, as I don't see that many requirements documents would contain things like: The application shall be free of SQL Injection vulnerabilities, or The application shall be free of CSRF vulnerabilities, as such a list might actually be (more or less) unbounded, and securing credit card numbers with HTTPS is an implementation ...


6

I'd just go with assumptions (or, unwritten assumptions if it should be more precise). Implicit, from another answer, doesn't quite work, because what was requested doesn't necessarily rely on them. For example, user must be able to change their password isn't implicit unless another requirement makes reference to a user changing their password with the ...


5

To me, a critical element of a User Story is that it captures Why and How a user uses the system. It is especially useful because it does not specify much in the way of how the system delivers the required functionality. When UI and Usability testing is needed, the User Story may be the most important document. Sure, you can have selenium verify that ...


5

I'm going to rely upon the SWEBOK (Software Engineering Book Of Knowledge) to guide my answer. In the Software Requirements* chapter, we're provided with more formal definitions of the terms needed for your question. Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. ...


5

The goal is to (1) deliver a system that satisfies the customer and (2) ensure the people using the requirements have everything they need. Provide the minimal detail level that performs both and you have answered your question. More specifically, does your organization have any requirements standards? I assume not from your question but common templates or ...


4

don't, unless he actually asked for it. Unless the manager wants to know what's going on beyond "your databases were written inefficiently", and the text in your question. DO document the old and new designs, but do it for the programmer doing your job. If management wants specifics, Visio its a good tool. But an abstract diagram listing "apps" and ...


4

You should be describing it using terminology that makes sense to the business, not to a HTTP client. For example, Scenario: Mark Order as Pending Given we have an Order Y // creates order When the user edits Order Y // click/load edit page And marks it for review // toggles tickbox #3 Then it should show up in the pending review ...


4

Passing acceptance testing is an indication that the system meets the users' requirements acceptably. As such, the requirements document is generally considered the source of truth for acceptance criteria. There will almost always be further elaboration of requirements during design. If these are truly an expansion of scope, the requirements document ...


4

The acceptance criteria defines when the application is finished. Or to put it another way, when you can ship it. It includes list of requirements that it has to fulfill. This means that some requirements (usually "nice to have" requirements) may fall off, and be implemented in next version. To expand it even further (taken from here) : Microsoft Press ...


4

I've been making my living from this kind of client since the late 1970s, so I can tell you it can be done. At that time of course most businesses weren't automated and so you pretty much had to smoke out your requirements. One client I had recently had issues with the technical dimensions - getting database accounts, server passwords, etc. I would get ...


4

They're the client. They get to decide what they want and what they don't want. The way you get them to tell you what they don't really need is by attaching time and dollar estimates to the unnecessary features. They will quickly realize which features are really important to them. Before signing a contract with a client involving money, you need to know ...


3

If you can find it, the old DOD-STD-2167A Software Requirements (SRS) Specification Data Item Description (DID) tells you what the DoD wanted in an SRS, and how they wanted it. This will give you a very good start. From memory, the SRS DID calls for a (boilerplate) Scope section, a Referenced Documents section, the Requirements section(s), and the ...


3

Have your system have log files that it can write to, which can be downloaded later from test versions of the device. (Make the logs circular, so that you'll always have the last X log lines, and limited memory requirements.) The requirement now becomes that postprocessing that log file shows that the battery was checked at least once during each second. ...


3

Assumption is a strong word. You definitely do want an assumptions section. But you also definitely do want that section to be validated for accuracy. If, for example, you are designing an app with the assumption that all of its users will be power users, then it had better be true. So basically, call it what you want (assumptions, prerequisites, ...


3

Well, your question seems a little bit vague to me because you really didn't mention what you need to know and what you get from the client, however, I always try to be realistic and think like the client in these situations. Let say you have money and you want to order a sport car, or a big house or the nicest leather jacket in the planet or whatever else ...


3

System acceptance should be against the customer's requirements. You are correct that analysis and derivation is performed against the customer's initial set of requirements. Often, customer requirements aren't enough to design and implement against, so it's necessary to elaborate on the needs of the customer, refine their requirements, and produce technical ...


3

This sounds like your agile system of working with the stakeholder is almost-but-not-quite working. Firstly, imperative user stories (you should give an example) are simply more detailed, so you can generate better tests from it. Taking this example shows that they do work, but are brittle in the face of changing customer requirements. If the customer has ...



Only top voted, non community-wiki answers of a minimum length are eligible