40

I think you've done your part by pointing out the problem and suggesting an alternative. If they insist that you do things that expose them to a certain level of risk, you should make sure you have a paper trail (and back-ups of it) showing that they explicitly requested this, knowing the risks involved. If you're really concerned, you could tell them that ...


35

A software design document can be at the level of a system or component, and generally includes: relevant goals or requirements (functional and non-functional); static structure (e.g., components, interfaces, dependencies); dynamic behavior (how components interacts); data models or external interfaces (external to the system/component described in the ...


25

First of all, as others have said, there's a difference between software actually working versus software being sold with a legal guarantee that it works. The disclaimer text you cite means that the original licensor you got the software from does not grant any kind of warranty. You can offer the software yourself with a warranty attached. The original ...


18

Technical specifications is a broad term. It describes any characteristic of an engineered system that must conform to a specific metric, within some degree of error. Functional specifications describe the expected behavior of a software system. Program specifications describe what the software is supposed to achieve. This differs from a functional ...


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 ...


13

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 out ...


12

It means that value types are stored directly where you define them, which makes them more efficient when compared with reference types. What exactly does that mean? If you have a local variable of a value type it will be usually stored directly on the stack (but there are many exceptions). If you have a field of a value type, it will be stored directly 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

Svick's answer is good but I thought I would add a few extra points. First off, the paragraph is flawed. Pointer types do not inherit from object. Values that are at compile time known to be interface types or type parameter types will, at runtime, be either invalid references or bona-fide instances of something that inherits from object, but it has always ...


11

When CSS Variables were introduced, there needed to be a syntax that does not clash with existing CSS versions, and allows future CSS versions to declare new properties. Properties that begin with a double-dash won't ever be used by CSS itself, so they can be used by other people. Since these custom properties aren't declared with any new syntax, they are ...


10

This is a standard disclaimer, that's often given for software, especially free software. It just means that the provider of the software makes no guarantees about the fitness of the software. He may very well be convinced himself that the software is good for what it does, but he doesn't want to enter the legal minefield that is guaranteeing it. The same ...


10

Do the easier of implementing the equation specified in the formula or spitting out the previous row's value, incorporating a prominent comment in the code explaining why it is as it is. At the same time, send your question back up the chain. If they get back to you with a spec change in time to implement it, then implement it. If not, your butt's still ...


10

I would say build a computer that has decent amount of power. The reason for this is that some languages have useful IDEs (ex: Visual Studios for .NET), and some of those IDEs require a powerful machine (ex: Eclipse for Java). Also, we computer people should have powerful and interesting computers. :) CPU, RAM, and storage (HDD or SSD) are probably most ...


10

It depends on what you're writing. If you're writing requirements, then the answer is "neither". Another question here on Software Engineering addresses the use of "shall" and "must" when writing requirements. The guidance that I use at work is that "shall" is used to denote any requirements that must be met for the software to be acceptable to the customer,...


9

Given the lack of this document how are we supposed to prove that the system does or does not do what it's supposed to to an auditor? Why is that a given? There is no rule of scrum that the only thing created is software. Make your acceptance criteria include "done when we have a detailed ISO 9001 compliant functional specification". Or, make that a ...


9

Because the headers are not part of the URL. The URL should identify the resource, on it's own, and should do it uniquely. The Accept (and the more useful Accept-Encoding) headers should not affect semantics of the request. They should indicate capabilities of the client so the server can format the response accordingly. If you do a HTTP call from JavaScript,...


9

Everyone agrees that documentation is important. However... Many programmers believe that code should be "self-describing," that the code itself should act as the documentation, and that therefore you don't need documentation. But that's only true to a certain extent. Code does not adequately document the relationships between components. It's ...


9

TDD is a design exercise. It does not mean "we have to design all test cases before implementing." Quite the opposite, in fact. In TDD, you repeat the following cycle many times: Write exactly one failing test. Write just enough of the implementation to pass that one test. Refactor It's okay to do a little bit of higher-level planning to make sure you ...


8

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 ...


8

With the processors used for embedded devices, there are three possibilities: The processor executes the code directly from flash/ROM. In this case, the code doesn't take any RAM away from the system at all. In this setup, the RAM and flash/ROM are typically mapped to different portions of the address space that the processor can address, so the maximum ...


8

Yes, it is possible. Mathematics and formal logic allows you to define computations that have exactly the properties you want and nothing else. And then the same logic allows you to prove that it is so. The problem is that it requires huge amount of effort to do so. Even writing a simple for loop might take days to validate. This is why this approach is ...


7

Technical specifications, at least in the form of a technical design, are part of the design documents, along with, for example, requirements lists, functional designs, user stories, graphics design mockups, usability studies, UML diagrams, business process diagrams, data model specifications, etc. Technical specifications of the type that you write after ...


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

Recall that a programming language is a specification, usually written in English -with the ambiguity of natural language- in some technical report. A programming language is not the same as its implementation in some compiler or interpreter software. A programming language (specification) is not only or mostly about syntax (which might be formalized with ...


7

Up-to-date, correct and well-designed documentation is a must. However, if it doesn't fulfill those three criteria, then it's worse than useless: It's a time/disk/soul-sucking hell. One of the problems I find in medium/large projects is that there is a fetish about documentation, but absolutely no notion of what documentation is for, namely: Documentation ...


7

If we don't know about [the] implementation, just the requirement specification, then go for interface. What that means is that you can sketch out an architecture by designing and writing the interfaces first, and defer writing the implementations that satisfy those interfaces to a later time. Let's say you're one of the designers of the Java development ...


6

The name you are looking for is "Syntax Diagram" or "Railroad Diagram". This question on Stack Overflow gives a good overview of some of the available tools for generating these types of diagrams. According to this answer by aleemb, which contains an email response from Douglas Crockford, the diagrams on json.org were made using Microsoft Visio, but ...


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