PROJECT-REQUIREMENTS

In software development, the focus is to offer value to the end users; to include features for their eyes. These are the functional-requirements of the project. But of course there is much ‘under-the-hood’ that the end user never sees. This includes content management systems (CMS) that administer the data, servers that provide that data, and developer tools and architectures to help organize the code-base. We call these ‘under-the-hood’ needs ‘non-functional’ requirements.

This quick primer answers “What non-functional requirements are necessary?”.

NON-FUNCTIONAL REQUIREMENTS

In each project, in addition to serving the end users goals, we must serve the needs of the development team; creating a realistic workflow for all team members, allowing for an extensible architecture for current and future functional-requirement features.

My point in writing this article was to get to a list of what non-functional requirements I setup in my apps or game needs. If you are already doing all this, great. MANY mistaken teams are doing NONE of these. Here is the list I use;

My Recommended Non-Functional Requirements

• Coding & Documentation Standards: Create a plan for coding standards and commenting practices. The plan should include a ‘bible’ written record of (what to do), the process and workflow to write the code as well as peer-review for compliance, and the buy-in from management to place priority (i.e. time in the calendar). Here are examples of my AS3 Standards and (in-progress) C# Coding Standards and recommended best practices e.g. Unity default folder structure. Consistency, pragmatism, and adoption are fundamentals here. Implementing such a plan is EXPENSIVE, so be sure everyone is on board. The benefits to readability, maintainability, and scalability are well-worth the effort.
  
• Configuration File – Upon project start-up, load an externalized set of name/value pairs (typically XML). This allows for developers (and others) to tweak values and reduces the need-for / frequency-of project recompilation. A huge side-benefits is that this ‘light and playful’ environment encourages experimentation.
• Localization – Even for English-only project, centralize (put all together) and externalize (separate from code – typically in XML) all display text. This allows for easier edits and translation to other languages if/when needed.
• Architecture – Sure, smart developers can create their own architectures, but smarter developers choose an off-the-shelf, 3rd-party architecture. Pave the cow-path, point your developers to 3rd party documentation and forums for help, and hire new staff (with experience in that architecture) more easily. If your team is not using ‘any’ architecture, that is probably a huge mistake. There are many available and are often specialized for each platform and project type (i.e. Flash Platform for Game project type)
• Restart Functionality – The app or game should have a restart button. This may be a functional-requirement. If so, great. If not, do it anyway. By requiring your team to implement restart (and garbage collection) your project will probably be far more efficiently written. This is an expensive feature to implement, but if done at the beginning it is very manageable.
• Zero-Memory-Leak Policy – The app or game may be ‘too simple to warrant optimization’. Regardless, do it anyway. Once you have the ‘Restart Functionality’ added, run a memory profiler tool on your project and ensure that with each restart the RAM usage properly reduces to zero (or whatever benchmark you set).  This is an expensive feature to implement, but if done at the beginning it is very manageable.

Game-specific Non-Functional Requirements

• The list above, plus…
• Pause Functionality – A fundamental test of good gaming architecture is ‘can it pause at any time?’. Even if ‘pause’ is not offered to the user, this requirement is helpful.
• Time-based animation – Your game algorithms should be infallible regardless of a faster-than-expected or slower-than-expected frame-rate.

CHAMPIONING DEVELOPERS’ RIGHTS

Depending on your team structure, you may have your software team developing the product ‘for’ the business team. Treating each department within your company as ‘clients’ helps to decouple the responsibilities and make hand-off of project tasks more clear and distinct. However each team, naturally defends their own interests, often at the expense of others. Within this setup, I’ve seen countless times that the dev-team must fight for the time to create non-functional requirements in addition to the functional requirements, where-as the business team’s focus is solely on the functional requirements. The business mind is concerned with ‘add a new button that does X or Y’ and to them that sounds simple. The Dev-team knows there is indeed a quick and dirty way to add that feature but also a more manageable, scalable, well-architected solution. It is a typical time vs quality discussion. Except the business team may not understand why spending more time (and money) is valuable when they don’t see more value in the end product.

Addressing developer’s needs helps to reduce burnout of your team. Happy developers are productive developers. Unproductive developers leave your team. Also an objective development leader can add ‘just enough’ non-functional requirements to respect the long-term plans of the project. Obviously a project with a long development cycle (days until launch) and long shelf-life (days between launch and unlaunch) benefits most from good non-functional requirements.

Arguing for the additional time needed to ‘do things right’ is a common struggle as dev teams champion their rights. Depending on the project, I can be on either side of this discussion. Generally I try to create an environment that makes the developers comfortable yet gets the job done. To facilitate that, I recommend separating time-estimations for functional-requirements from non-functional. One methodology is to take the total time estimate for the project or milestone’s functional requirements (including buffers for unknowns) and then calculate 20% additional. I offer developers that 20% to use as they see fit.

For example the business team can offer to the developers; “Ok, we all agree that our next milestone will take 400 man-hours; so you (developers) will get 480 and can allocate the 80 hours to improve code quality (beyond our minimum standards) and build-out the architecture (beyond today’s immediate needs).” Over-architecture and over-planning are dangerous, so giving free-reign to developers to ‘make it perfect’ is not cost effective, nor does it really improve the project or product. If developers feel they are hitting some (80% perhaps?) level of comfort with their code-base, that is a good balance. This is my personal opinion based on years of experience on hundreds of small to mid-size software projects.