FLURPS is an acronym for six components of
well-rounded big data designs: Functionality, Localizability, Usability,
Reliability, Performance, Supportability. Here's the case for using
this template.
I've
been advocating for customer-centric design as long as I've been
designing solutions for customers. I still do this, because I have to.
It's remarkable to me that after decades of building high-tech solutions
for customers, technologists still seem to build solutions in an IT
vacuum and then get upset when customers don't find them very
functional.
Gold plating is a term used to describe developers who
infer customer requirements and subsequently build features that the
end users never requested -- because the developers know better.
Unfortunately, data scientists are carrying this tradition forward with
analytic solutions. That said, I wouldn't categorically dismiss any
requirement that doesn't come from a customer or end user. It may seem
odd coming from such a strong advocate of customer-centric design, but
there are aspects of a well-built solution that customers don't know or
appreciate.
When designing a big data analytic solution, make sure
it includes a well-rounded set of requirements, including ones that the
end user won't directly know about or care about.
What's FLURPS?
FLURPS
is a great acronym that I learned as a young computer Big Data Training in Jaipur, and
it works great as a template for building well-rounded analytic
solutions. FLURPS stands for: Functionality, Localizability, Usability,
Reliability, Performance, Supportability. It seems like a lost acronym
that I'd like to resurrect to help us design and build better solutions.
This funny-sounding acronym reminds me of a big, hairy puppet like Mr. Snuffleupagus
-- that's why it has stuck in my mind for so many years. Let's go
through the different elements of FLURPS and how they can enhance your
design.
Functionality
Functionality remains the key
component of design; it represents all the features the customer knows
and wants. When building a requirements document, most analysts separate
functional from non-functional requirements, which is a good practice.
Furthermore, functional requirements should always take precedence over
non-functional requirements. Never sacrifice functional requirements for
non-functional requirements -- you should satisfy non-functional
requirements in addition to functional requirements.
Localizability
Localizability
handles geographical concerns such as language. Internationalization
(or i18n, for those in the know) is closely related to localizability in
that it architecturally provides the technical infrastructure to
localize a solution. Knowing that your recommendation engine will be
used globally, you may internationalize it by automatically sensing
where your user is located, and then localize it by providing, for
example, German-, Russian-, or Chinese-specific content. Bear in mind
that good localizability extends beyond language translation and caters
to cultural differences in functionality.
Usability
Usability
deals with the customer experience. This is a pet peeve of mine -- I'm
tired of seeing analytic solutions that force the user into the mind of
the developer. For instance, it's very common to see use cases where a
batch operation seems obvious, but the solution only allows single
transaction processing. If I could possibly have hundreds of input
variables to my predictive analytics engine, why should I have to create
them one by one?
Although usability seems like it should fall
into the functional category, it does not. Most customers don't know how
to design a usable solution; however, they know when it's not usable.
Putting a user experience expert on your team is a fantastic idea.
Reliability
Reliability
handles the stability of your application. Reliability is not something
end users contemplate because they assume your solution will be stable;
when it's not, frustration can quickly escalate to extreme
dissatisfaction.
You must build reliable solutions. How many times
have you lost work because your system crashed? And by the way, a cute
little icon telling you that the system crashed doesn't help. Build
requirements into your solution to recover from exceptional situations
and gracefully exit only when all possible routes of recovery are lost. I
once designed a web application that went through four or five levels
of exception before it finally, gracefully quit -- after saving all of
the user's work. The users never knew the application was going into its
third and fourth level of exception, and that's the way it should be.
Performance
Performance
is a bigger deal than you might think. I recently trained a group of
users on a new web-based system that would on occasion take several
minutes for a submenu to appear -- the industry standard is between two
and three seconds. The performance of the system broadcasted the quality of the rest of the system, and it wasn't positive.
I know performance issues can be difficult to track down, but that's
your problem, not the users. Make sure reasonable response times are
documented in your requirements and thoroughly tested when the system is
built.
Supportability
Supportability is the last, but not
the least important, component of a robust design. Whether you're
designing a product that will be used by customers or an internal system
that will be used by employees, it's vitally important that the
operations group is in a good position to support the solution.
For
analytic solutions, supportability often extends beyond requirements
into organizational design. The instrumentation on an analytic solution
is often sophisticated, so it's important to staff the operations
function with very knowledgeable technicians -- maybe even other data
scientists. When I'm putting together a development team, I often
include at least one person from the support team; this way, they can
influence the solution's design from the perspective of someone who's
going to support it.
