Hot answers tagged

5

// fx abc if (string.IsNullOrEmpty(value)) { throw new ArgumentNullException...} Please do not do this. This is a technique that was invented in the previous millennium and is best left in that previous millennium. Follow this rigorously and the code quickly becomes unreadable. This defeats one of the primary purpose of code, which is to make it ...


4

There are typically layers to requirements, especially if the software is complex or when specifying a system that includes both hardware and software elements. Depending on the complexity of the system, you can have any number of layers. I do disagree with your definitions, however. Requirements always address what the system does (functional requirements ...


1

You were right, the three letter codes and excel tables weren't a good method for tracking requirements. I have experimented with other systems and came up with this. I divide the tests into UsesCases and ErrorHandling. This allows me to better focus on what I am testing and I can avoid weird naming conventions so that each test has a pretty clear and ...


1

I'm not sure if you are asking for high-level features, let's say something you work on for a couple of days or low-level ones. For the first one, if you have a bug/feature/task tracking system, e.g. JIRA, you could automatically match the code/code changes with the feature by including the ID of the task to the commit message e.g. [FOO-312] Add basic user ...


1

For business rules I think @Joppe pointed out to the UML we all were thinking. Use Case Diagrams does an excelente overview of how Actors/Roles interact with the system and what system does. For complexe Use Case, additional info explained textually will help a lot (preconditions,postconditions,dependencies on previous UC executions,etc) There are ...



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