(Professional Business Analyst Training organisation) FURPS+? (Professional Business Analyst Training organisation)

Some requirements are functional and some other are non-functional in nature also they can segregate at the same time some requirements can classify technology-independent and others technology-specific. So this give way for the need and necessity of classification that will allow organisations to think about different aspects of requirements.

FURPS is a technique to validate the prioritised requirements after an understanding with client’s needs and necessities. The acronym FURPS is Functionality. Usability, Reliability, Performance, and Supportability, over a period of time and grave need raised to see the solution from more dimensions gave to emergence of FURPS+.

This FURPS+ technique made the requirements classification to stress on understanding the different types of non-functional requirements more.      

Traditional BA (Waterfall) Functionality - The F in the FURPS+ acronym represents the main product features that are familiar within the business domain of the solution being developed. The functional requirements can also be very technically oriented. Functional requirements that you may consider to be also architecturally significant system-wide functional requirements may include auditing, licensing, localization, mail, online help, printing, reporting, security, system management, or workflow. Traditional BA (Waterfall) Agile BA Requirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules. Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.   Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details. Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively. Focuses on getting a ‘sign off’ on the requirements. Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them. Often there is a wall between the BA/Business and the Development team. Agile BA (Often called as Product Owner) is part of the team. Tends to dictate solutions. Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions. Long turnaround. Quick turnaround. Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document. Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.

  Usability - Usability includes looking at, capturing, and stating requirements based around user interface issues -- things such as accessibility, interface aesthetics, and consistency within the user interface. Reliability - Reliability includes aspects such as availability, accuracy, and recoverability -- for example, computations, or recoverability of the system from shut-down failure.

Performance - Performance involves things such as throughput of information through the system, system response time (which also relates to usability), recovery time, and start-up time. Supportability - Finally, we tend to include a section called supportability, where we specify a number of other requirements such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, localizability, and so on.

+ The "+" of the FURPS+ acronym allows us to specify constraints, including design, implementation, interface, and physical constraints. Design constraints - A design constraint, as the name implies, limits the design -- for example, requiring a relational database stipulates the approach that we take in developing the system.

Implementation constraints - An implementation constraint puts limits on coding or construction - standards, platform, or implementation language. Interface constraints - An interface constraint is a requirement to interact with an external item. When you develop within an enterprise, quite often you have to interact with external systems  

Physical constraints - Physical constraints affect the hardware used to house the system - for example, shape, size, and weight.