Fotolia
Consider nonfunctional requirements for content services
If developers do not build security, auditing, reporting and accessibility into content services from the very beginning, they will face major challenges implementing them later on.
Many organizations are adopting the content services approach to solving enterprise content management challenges. When organizations implement content services properly, business requirements are embedded in the back end and user experience evolves independently from the platform. This division of labor makes both users and business owners happy.
However, developers also need to consider nonfunctional requirements -- such as security, auditing, reporting and accessibility -- early in the development process in order for content services to be successful.
Security
Have you ever gone to release an application and had to wait because a security scan fails? Nobody ran the scan until the team was almost done building the application, because it would be pointless to scan an application for security holes when it isn't complete. You wouldn't test the security of a half-built house, would you?
Moreover, the security team wants to scan a relatively complete version of the final application to save time. The problem with this approach is that waiting to address security requirements late in the process makes them harder to fix.
It requires weeks -- sometimes months -- of working with security to develop adequate resolutions for every issue that the scan finds. Furthermore, encrypting content as it enters an application is easy, but it is difficult to encrypt content that people are actively using to do their jobs.
The security and the development teams are both at fault here. The security team should have been involved from the beginning to ensure the development team understood the security requirements. The development team needed to reach out and have the security team educate them on the necessary nonfunctional security requirements. Regardless of whether the organization achieves this by using DevSecOps, improving communication or some other means, it needs to be done.
Auditing
There you are, performing a final application demo, and the compliance officer asks how the application is going to audit the information. In modern application architectures with multiple layers of services and microservices, it is not easy to identify where auditing will take place. You could track at the request level, in the content repositories, within the business logic or use a combination of the three.
It is best to make a decision early on, because adding auditing capabilities into the system at the last minute can lead to a hodgepodge of audit information and risk not capturing all the actions. The time to discover a hole in your auditing is not after legal action begins.
Once you identify where to capture the information, there are more questions to consider. How do you collect the necessary details at each layer of the application? Can you reconcile unique identifiers with human-readable information? Will people be able to interpret the information in five years?
Reporting
How will you know if your application is useful? And how will you measure improvements as the application evolves? Metrics are important not only to improve how people work, but also to prove to decision-makers that an application adds value.
Reporting seems like an easy requirement to implement. Even if you haven't built the reports when you release the application, you need to capture the data on day one. If you do not capture the information to report against, you can't develop reports or perform any analytics.
Accessibility
Accessibility is another feature that developers often overlook. How will users who are blind, deaf or use screen readers interact with the application? For example, fancy icons may look nice, but may be difficult to navigate for people who don't use a computer mouse. Gray text on a white background is a popular design choice, but low-contrast colors can be difficult to read. Similarly, applications that depend on color to provide feedback to the user are not accessible for colorblind users.
Application prototypes and demos will quickly fall apart if you make these changes last minute.
It is critical to include these requirements, along with data integrity and disaster recovery, from the beginning. It is difficult to change core processes to accommodate these mission-critical, nonfunctional requirements, leading to an application that is much harder to support and grow.
Other requirements
Developing any application comes with delays. There are always unknown functional requirements that you and the business will discover along the way. That is why it is critical to plan ahead in order to preemptively prevent delays from nonfunctional requirements. Every application needs to meet the needs of the users, the business and the organization overall in order to be successful. If you develop nonfunctional requirements in a scalable manner, you can focus on solving business problems and providing value to the organization.
