When considering specification requirements, is it necessary to “eliminate sins”?

Question

When considering the specification of requirements (which includes functional, non-functional requirements, restrictions, etc.), no matter how small or large they are “deadly sins” committed by the authors for the search?

Please list no more than 7 of the most significant things (in order of decreasing severity) that are performed (or not performed) in the specification of requirements, adversely affect the quality of the software product. Less than 7 is excellent.

Answer 1

OK, this is over 7, but the following attributes have good requirements:

• Unique Are there any other requirements that are similar?
• Identifiable . Can a requirement be uniquely identified? Can this be traced throughout the development process?
• Full . Is something missing or forgotten? Is this a circumstance? Does it include everything you need to be lonely?
• Accurate . Is it correct? Does he define the Goal correctly? Are there any errors?
• Unequivocal . Is the description accurate and not vague? Is there one interpretation? Is it easy to read and understand?
• Sequential . Is the description a function written so that it does not conflict with other elements in the specification?
• Relevant . Is a statement required for a function? For more information, information that should be ignored? Is this customer's original need traced?
• implemented . Could this be done using staff, tools, and resources within a specified budget and schedule?
• The code is free . Does the specification adhere to the product definition and not the underlying software design, architecture, and code?
• Testable . Can they be tested? Enough provided that the tester can create tests to verify that the requirement is met?
• Priority Is it more or less important than other requirements?
• Uses an active voice . Does the specification use active voice? A passive voice does not always indicate who or what performs an action.
• Categorized . Is the requirement logically grouped with similar requirements? Possible categories are: Behavioral, Performance, Interface, Data Structures / Elements, Implementation, Conformance / Quality, Operational (reliability, safety, Security), Derived / Designed.

A decent requirements tracking tool can automate / enforce some of the above functions, such as Identifiable, Priority, Classified, but only a review of the team can verify the rest. The key is to teach your team these attributes, get their practice, read both good and bad examples of requirements, and create an effective review process that checks the requirements early enough in your life cycle to have an impact on processing activities.

Answer 2

Missing requirements are much harder to catch. Separating requirements into clear sections (e.g. security, performance, style, etc.) can make this easier.

Answer 3

Features, Time, Quality - select any two. make sure that the requirements do not impose all three on your team.

Cancel the requirements that are trying to control your process.

Request clear prioritization from the start.

Insist on clear eligibility criteria for each requirement.

Answer 4

The requirements should be specific and unambiguous as to what is needed, but should be less so on how to satisfy the requirements.

Answer 5

Fulfillment of Assumptions - Double-check that everything that looks like an assumption has actually been verified.

Answer 6

Poorly worded sentences containing more than one requirement. Separate them somewhere to make them clearer and easier to note how this is done.

Answer 7

Requirements that are not so easy to verify how they are met. - Go to the form, which can be more easily marked as met or not when viewing.

Answer 8

The requirement does not indicate who / what is doing the thing.

"The invoice is reconciled to the purchase order." 

Does this mean that the system is doing something or the user?

Answer 9

Worse than what I saw in the project that I encoded for: -

 The system shall interface to SAP as required. 

Firstly, the requirement "as necessary" in it is stupid. This line should cost 400 thousand dollars. The client continued to point to him and say that it says that you are going to do blah blah blah blah.

Answer 10

Super strict - if possible, indicate appropriate tolerances.

Answer 11

Minor requirements are bad.

Unused and non-measurable requirements double.

Answer 12

Naturally, it all depends on what requirement you receive. I'm used to a typical Gui or web application, batch processes and

• First set standards that should not be defined in each specification; refer to them
• Do it as little as possible - you can rarely read a 200-page document and remember everything.
• Be specific, slow, specific
• Examples (figures, accounting records)
• Explain the purpose before the function description
• include performance standards, sustainability standards, deployment instructions, documentation for required operations

I also have one tip for the reviewer: know the topic

You must have a very detailed knowledge of the context of the requirements, the specific needs of the client, the technical environment and, possibly, the most important, to whom this requirement will be addressed and at what level of global understanding they have.

I did very poor experience in projects when many people considered specifications, because their individual knowledge was very shallow. You get feedback at the same level, mostly formal corrections, but deep specification flaws will be discovered very recently in the project.

Answer 13

Avoid “weasel words” - any language that can be taken out of its context and sounds badly bad.

Make sure everything is completely clear: undefined == Bad Thing (tm)

Answer 14

My recommendation and what I always do before a new project is to double check the checklist on Page 42.43 of code Steve McConnell completed

Answer 15

All knowledgeable wikpedia have a good overview for requirements - http://en.wikipedia.org/wiki/Requirement#Good_requirements . I would say that of those points, lack of verifiability is what is the most common occurrence. Understanding the big picture is important in life, however you need to clearly state things in your requirements, for example. The system must respond quickly. Instead, the system should respond to all requests in less than 2 seconds.

Answer 16

• Separation of functional, architectural, interface, non-functional requirements.
• Using unambiguous and sequential writing to describe objects
• Clear entry and exit criteria for use cases
• Have flow charts (mind maps serve the same purpose as UML and are easier to draw).
• Define the scope in understandable terms, what is covered and what is not, and where to find those that remain unknown.
• Has a traceability matrix

Answer 17

You might want to read some of the Requirements Management and CMMI .

Also visit the Requirements Checklist and google for “Good Demand Criteria”.

They are specifically designed to create processes that assist in software development.