8

I'm in R&D working on a new software product.

Management understandably focuses on the primary features that most obviously give a customer an advantage. But there are many requirements that can be seen as important as well (ex. performance, future extensibility, data traceability, security, smooth UI). These implicit requirements are probably the larger in number for any product, and if unfulfilled can lead to an unhappy customer.

I'm afraid that it is somehow expected that during development these things will become automatically implemented. For me though, everything is an atomic aspect that requires it's own attention and development effort.

I have a feeling that management may be too busy to pay too much attention to such aspects. For the sake my own developer pride, quality control, and being able to account the effort I spend, when and how should I document and communicate implicit requirements?

(i.e. features that exist in a product, but which haven't been explicitly talked about with either the customer or management)

Clarification

Thanks for the interest in the question, the main gist of the answers up to now seems to be:

"You need to make implicit requirements explicit."

Rats... that didn't occur to me.

The requirements I mean can be of the following types:

  • The customer can't hear about these requirements, because I will be presenting a long list of ways in which the product can fail, instead of talking about how it will make them happy.
  • Busy management feels that I'm wasting their time, when I talk about "obvious" features.
  • I will only be able to describe some of these requirements during implementation. During planning I may just have a gut feeling that a particular issue might require focused effort during development.
  • I'm not at the necessary height in the company totem-pole to dictate my working conditions.

I'm asking for guidelines how to semi-formalize [implicit] requirements, while putting in less effort than for full-blown requirements, but keeping me prepared for judgement day, so that I'm not caught empty handed.

Rafael Emshoff
  • 553
  • 4
  • 18
  • 5
    Do your "implicit requirements" translate into anything that's actionable? And if it's actionable, do you have a way to determine whether the actions taken have met with success? It's kind of silly to do something or try to get people to do something if you don't have a clue about how to tell whether the action has been successful. – Vietnhi Phuvan Nov 12 '14 at 16:04
  • 5
    For the record, both performance and security should under no circumstances be implict requirements. Making them implilct is why so many systems have bad security and worse performance. – HLGEM Nov 12 '14 at 16:42
  • What is your role here? Are you the Requirements writer? –  Nov 12 '14 at 16:50
  • @Joe Strazzere I'm the developer – Rafael Emshoff Nov 13 '14 at 17:08

7 Answers7

11

Define everything. The only potential negative to doing so is that you may get something back complaining that they feel you're stating the obvious.

State the obvious then.

This is key: Anything you don't define can get thrown back in your face with "you never told us..."

Anything that isn't defined can potentially blow up in your face. "Better safe than sorry" are excellent words to live by.

Chris E
  • 211
  • 1
  • 5
  • 1
    To expand upon this: Obvious to one person isn't necessarily obvious to others. This becomes much more important when dealing with outsourced developers and crank that up a few more notches when you get to offshore developers. Spell **everything** out explicitly and assume nothing. As an example, I dealt with an issue recently where ages were being calculated improperly (an off-by-one error). It came down to a cultural issue in how people "counted" age when speaking - "in his 18th year" (born somewhere between 17 and 18 years ago) vs. "18 years old" (has completed 18 orbits of the sun). – alroc Nov 13 '14 at 01:22
9

The industry term for such requirements as you describe is called:

Non-Functional Requirements

They should under every aspect be identified by technical resources and added to the project plan as atomic units of work. If you are doing an Agile project then they would be written in user story form and added to the backlog to be dealt with. As the technical resource you need to advocate for the time to work on these and make sure that they have appropriate priority during your sprint planning or project planning session with the business. Furthermore QA needs to devise an appropriate test plan for these units of work as well.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
4

As it happens, we had some of those implicit requirements bite us because they were not defined and thus QA didn't test them and the bugs went to production and were not found for some time causing not only the hassle of explaining to the customers the problem and why it wasn't found earlier but an actual legal problem for our company. (It was a report that dealt with information that had to be reported to the government.)

If it is important enough to do, it needs to be tested and thus it needs to be part of the requirements.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
  • 1
    Yikes. Legal dependencies should *always* be explicit, never implicit. –  Nov 12 '14 at 16:51
  • The implict part had to do with how we were handling exceptions and what those really should have been. The people who did it thought they were just common sense but since they introduced a bug... – HLGEM Nov 12 '14 at 18:37
3

Making implicit requirements explicit is the correct answer.

About your follow up constraints:

The customer can't hear about these requirements, because I will be presenting a long list of ways in which the product can fail, instead of talking about how it will make them happy.

Imagine you're an architect, you design buildings for big companies.

Big Co. Inc. asks you to build a skyscrapper for them by the shore. It has to have a swimming pool on the roof, and another pool on the 10th floor. It has to have a wall garden covering the outside wall from the 15th floor to the 17th.

This are the customer's requirements. Would you hesitate to add to the requirements list the requirements to have the building support its own weight plus two pools full of water and a hughe wall garden?

Would you hesitate to add that it has to have plumbing, electrical wiring and a system to fill the pool with water and keep the water clean?

You are the architect, you know what is necessary for a building, that's what they're paying you for.

You know that a building with more than three floors will need an elevator, you don't need anyone to tell you that.

Busy management feels that I'm wasting their time, when I talk about "obvious" features.

So the elevator is obvious. As obvious as it is, it still has an impact in the overall cost, the overall workforce required, the ETA for the project, and probably other aspects.

I will only be able to describe some of these requirements during implementation. During planning I may just have a gut feeling that a particular issue might require focused effort during development.

This is where the architect analogy breaks, mainly because of the fluid nature of IT. My only advice here is that you may benefit from an iterative process that allows you to plan for the unplanned. Agile seems pretty popular.

I'm not at the necessary height in the company totem-pole to dictate my working conditions.

Your company should have someone responsible of making sure the requirement list is complete.

  • If they don't they have a big problem, try to get them to fix it or start polishing your resume.
  • If they do but that person didn't do his job right, call him on it and escalate as necessary.
  • If they do and that person is you, but you weren't given the authority to do your job, then they're asking you to do something impossible, your best move is not to play (aka try to get them to fix it or start polishing your resume).
GnP
  • 169
  • 4
2

Requirements can come from any source, as long as they are traceable to where they came from and not in conflict with each other. Customers can provide their requirements, but requirements also come from laws and regulations, industry standards, business needs, and even prior experiences learned by delivering similar products to other customers.

Each of these requirements should be captured in whatever method you use to capture requirements so that it's not forgotten. Doing this will also allow them to be compared to ensure that an added requirement isn't actually in conflict with a customer requirement or a customer requirement isn't in conflict with regulations, for example.

You should be capturing these requirements and managing them right from the start of the project and flowing them down to the staff that is designing, implementing, and testing the software. Doing this will ensure that everyone fully understands what the delivered software is supposed to be.

However, when you do add one of these requirements, you should verify it with the appropriate stakeholders. You can't simply add requirements without ensuring that you can still deliver the software within the intended schedule and budget.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
1

This is when having a diverse team that has people who specialize in different areas comes in. It also requires more sr. people on the team to lead the rest.

For example performance, future extensibility, and data traceability should really all be things that are thought of from the start. They aren't a checkbox that you can just go back and add in later, they need to be in the foundation of your design.

As for security, this is when having someone who is familiar with this area be on your team from the beginning to help with the design process.

UI design has the tendency to bite a product if not done properly. Having a UX person on the team doing mock-ups and screen flows for the team is where this comes into play. But, again, this is something that should be done up front.

Your requirements might be a website that allows users to look up current the current inventory of a local store. How you design that system is where those implicit requirements fall into play.

From a project management stand point, this means that there needs to be design time in the budget, as well as proper testing time. There should also be check-ins with the client to show them what has been done to make sure you're on the right track.

Tyanna
  • 9,528
  • 1
  • 34
  • 54
0

Any implicit requirements that will end up causing work for the team should be made explicit.
If not, they will end up either

  1. biting you later when people bring them up anyway, causing overruns on development
  2. ignored and later reported as bugs
  3. being implemented anyway, despite not having been scheduled, causing overruns and bug reports because they were not implemented as the customer had thought they should have been but never mentioned.

So by making implicit requirements explicit you save yourself a lot of headaches.

jwenting
  • 9,783
  • 3
  • 28
  • 45