One make sure that all requirements are technologically and realistically possible for a reasonable cost. To do so, bring in the technical specialist team and discussed a requirements and potential solution options.
There are two examples of feasibility:
Poor. “the web system as intrusion detection functionality must capture the reason for any intrusion attempt”
Excellent. “the web systems intrusion detection functionality must capture the date, time, and IP address of any potential intrusion connection, as defined by intrusion-suspect criteria factors”
After you decide that everything on the list is necessary, requirements must then be prioritized. This is to make sure in case completing all of them right now is not possible. Rent requirements from the business perspective, the technical perspective , or both.
Facilitating these two perspectives involves some give and take:
From a business perspective, prioritize requirements according to their value, level of risk, or expected frequency of use in the business.
Stakeholders can characterize what they need by using declarative statements such as that they must have X, it should be present, or X would be nice to have.
Also identify requirements that may be considered a delighter, or something stakeholders may find unexpected unexciting and value adding. This is often particular important within commercial situations.
From the technical perspective, the technical team may need to implement requirements in order of technical importance or simplicity rather than by business importance.
Requirements for compliance with governmental regulations, operating system upgrades, and other drivers may not have been initiated by the business but are still important to the business. Make sure the business understands why you are prioritizing these items.
To ensure that your requirements are excellent, consider stating them in many forms such as textual statements, diagrams, pictures, and so on. The characteristics of an excellent requirement applied to any form of communicating requirements.
It is worth mentioning a particularly valuable form of prioritization called MoSCoW.
Every requirement should be classified in one of the following prioritized states:
I will now go into much further detail.
For each requirement, you have many different consumers, and you do not want to overload any of them with requirements that they do not need to worry about, otherwise they may miss the things that are important for them.
For this reason, requirements are broken down into four major core components:
Organizing and presenting the requirements according to the core component they describe, helps the consumer focus then knowledge building and requirements assessment in support of the work that they need to do.
They will not need to sort through and interpret or eliminate the relevant requirements, they can instead review and understand requirements directly related to to the portion of the solution that they are responsible for creating.
In addition, organizing requirements by their core components helps you because you cannot call listed plea at one core component and then cross check that crossed the other core components to seek out inconsistencies and gaps and ultimately identify missing requirements.
Here I will discuss each of these core components in more detail:
Data is information that frequently gets stored. The data size can vary enormously such as such data on the Internet, or small do everyday data such as invoices, billing, sell projections, and personnel records.
The characteristics of the Business day to define what each piece of data is, what it is for, what it means, how it is represented, and what relationship it has two other pieces of data.
You typically stored information in a database with both the physical and a logical design. The database is a physical place with structures consisting of tables and columns that capture and organize all of its data.
Physical database designs represent the technical requirements for how the business data will be stored, and these are frequently designed by the database administrators or date are engineers.
The logical design reflects what the solutions functional data requirements are to support the business needs. It is called logical because it shows logically how the business thinks about the data and it’s interconnected relationships from the business perspective.
In business analysis, we frequently defined logical representations of day to requirements often the information is elicited from the business stakeholders.