It's now time to translate the business needs into more formal business requirements. Whilst undertaking this process, stakeholders are also required to look at the feasible alternatives associated with closing our capability gap. Feasibility assessment will allow stakeholders to concentrate their efforts on defining business requirements around the most feasible solution space. Note that they're not choosing or defining the solution at this stage, but merely assessing the most likely solution option when looking at their requirements. This avoids wasted effort and also focusses the business requirements making them more useful in the following stages. For example, earlier I mentioned an example of a military capability gap, associated with monitoring national borders. The likely options for doing this, that is the possible solutions basis, may include satellite surveillance, surveillance from uninhabited aerial vehicles, surveillance from conventional aircraft, or surveillance from warships. These may all be technically feasible but the business needs and constraints are likely to rule some of those options out. For example, we may not have the money or time to establish a satellite based system. We may not have the human resources or desire to establish a warship capability, the feasible options, therefore, might either be conventional or uninhabited aircraft. The stakeholders responsible for extracting business requirements should therefore concentrate on the feasible-solution spaces only. These business requirements will be more formally stated than needs, and will eventually guide the development of engineering requirements for our system. Whilst the business needs paint a picture of the problem and the desired solution. The resultant business requirements are a further decomposition of the needs, so that we can understand exactly what the business requires from the ultimate solution when it's deployed. We'll capture these requirements in a structured or organized artifact, that we're going to call the business requirement specification or simply the BRS. Once the business requirements are established in the context of the business needs, the stakeholders can document and record all of that information. We're going to propose recording all of this information in the form of an artifact that we call the business needs and requirements, which consists of a preliminary lifecycle concept document, or a PLCD. And a business requirement specification or a BRS. Once produced and updated, we'll conduct some form of requirements review with our key stakeholders and the organizational decision-makers, in order to review and agree to the PLCD and the BRS. That will then allow us to pass this information onto the groups of more operationally focused stakeholders for them to refine and further develop our requirements. We have endorsed business needs and requirements from the previous work, this shows that management are confident that there is a need existing for a new or improved system. And that they understand those needs sufficiently to move on with the process. We have a preliminary life cycle concept document that describes all of the life cycle concepts, including concepts for acquisition, operations, support and disposal. And we have a business requirement specification that defines the agreed business requirements for the system. We now look to build on this work by using selected groups of more operationally focused stakeholders. These stakeholders are more on the coal face so to speak, and are able to look over the business needs and requirements and give them a more refined feel. To acknowledge the refinement process, we're going to call the resulting work the stakeholder needs and requirements. In performing this work, the operational stakeholders will look over all of the previous work, including the mission, goals, and objectives, the scenarios, and the life cycle concepts. They may develop more refined scenarios that are sometimes called vignettes, to capture a more detailed and operational nuance. They will also refine the validation criteria in order to communicate how stakeholders could be convinced that their expectations have been met. We will refine the preliminary life cycle concept document into the initial life cycle concept document, or simply the LCD, and we'll refine further the business requirement specification in to stakeholder requirements pick or simply a STRS. In some cases the refinement might be minor but in other cases the LCD and the STRS may represent quite substantial developments. Regardless, we will finalize their effort by reviewing both the LCD and the STRS via another requirements review. Armed with the endorsed life cycle concepts in the LCD and the endorsed stakeholder requirements in the STRS, we're now in a position to embark on a major systems engineering task within conceptual design. This task is generally dominated by a system-level analysis. As an introduction to this process, I need to warn you that performing a solid requirements analysis, and writing effective system level requirements, is a very tough job. It's a job for a team of people, because more heads are better than one. It's also a job for experienced people, because practice makes perfect. Although, you're going to find perfection very difficult to come by in the requirements analysis space. And, it's also a job that requires iterations, reviews, and re-working. We're aiming to describe what the system has to be able to do in order to satisfy the stakeholder requirements in the STRS. We try to avoid specifying how the system should be designed at this stage. If we start specifying the design at this stage, we risk overlooking innovative ways of solving the problem. We also risk taking responsibility for a design that simply doesn't work. We should specify what we want the system to do and leave the design to the experts we engage to perform the preliminary and detailed design later in the process. We'll record the system level requirements in an artifact that we're going to call the system requirements specification, or the SyRS. As we're drafting this artifact, we establish and maintain traceability from our system requirements back to the stakeholder requirements just to ensure that everything we specific has a reason for being there. We also trace from the stakeholder requirements forward to the system-level requirements, to ensure that we've addressed all of the stakeholder requirements. Traceability by forwards and backwards between different levels of requirements is a cornerstone of requirements engineering. In this case, it's traceability between stakeholder and system level requirements that's of interest to us. Later, the traceability of interest will be between system level requirements and lower level design requirements of our solution. A useful starting point for our requirements definition effort is to establish a requirements framework, or a requirements breakdown structure. We've probably already established a requirements breakdown structure in the previous process, where we were looking at stakeholder requirements. If it's already established, we can review, refine, and reuse that structure. If it hasn't already been established, then now is the time to get one in place. An example of a requirements breakdown structure, or what we call an RBS, for a burglar alarm is illustrated. The structure helps us when we're performing requirements work because it allows teams of people to be working on the task at the same time without duplicating the effort. For example, we could have one team or one person looking at our detection requirements, under heading two, whilst another team or person is looking at reporting requirements, under heading four. The RBS provides a common framework against which different teams of people can have discussions. And it will provide a common framework against which our requirements can be allocated when the time comes. This will allow similar requirements to be grouped and allocated to single sections within the framework, assisting in correcting conflicting requirements. It also helps us guard against duplication or omission of our requirements. We then start performing our system level requirements analysis. We're looking to answer some pretty fundamental questions about our system. What does the system need to be able to do? This is where our functional requirements help. Functional requirements define what the system needs to be able to do. How well does the system need to be able to perform those functions? Performance requirements associated with our function requirements define performance levels. What other characteristics are required of our system? These are typically emerging properties or non-functional requirements associated with our system, these might include factors like reliability, usability or maintainability just as examples. What other systems are involved with our system? We may need to define external interface requirements. Probably specialized examples of functional requirements associated with our system. And under what conditions is our system expected to operate? We also need to be able to define how we're going to verify our system performance against those requirements. It's important to note that verification is a term in systems engineering, meaning to confirm system performance against specified requirements. Recall that we've used another term, validation, in previous discussions, to mean confirmation that our stakeholders are being satisfied. Often you'll find that people use those two terms interchangeably, which is not correct. Also, people often combine the terms to describe the process as being V and V. Unless that acronym V and V is used very carefully, it may also be used incorrectly. If we are talking about confirming a system against its specified requirements, we're talking about verification. Establishing verification requirements at the same time as writing functional or nonfunctional requirement statements, is considered to be good requirements writing practice. It forces the author of the requirement to ask, how would I confirm this requirement? It often highlights problems with the requirement statement and forces the author to revise the statement in order to make if more verifiable, this is a very worthwhile exercise. While we're writing our requirements, it's also recommended to allow authors to record rationale or notes associated with each requirement. This allows the author to explain the background to the requirement for future reference. Traceability can provide some rationale for the requirement, but it might not be enough to explain why the requirement exists. Rationale may protect requirements from being changed in future, without due consideration as the why the requirement was there in the first place. I'll give you an example of where I have benefitted in the past from recording rationale. I remember being responsible for writing requirements for a large project a number of years ago. One day, about five years after finishing my job, I received a phone call from someone who was still on the project. And I asked why I had to sign a specific performance level, against a specific requirement. The caller said that I'd recorded a rationale pointing to a meeting that I'd had with air traffic controllers, relating to controlling air craft that were flying in tight formation. Once the guy reminded me of the rationale, i.e, the meeting. I was able to remember and explain exactly why that requirement was written the way it was and who the caller should refer to for further information. In the absence of that rationale, I think I would have struggled to recall why the requirement was written that way, and it's possible that, that requirement would be been changed with possible adverse consequences on the relevant stakeholders. In this case, on the air traffic controllers, who were going to have to try to control aircraft flying in tight formation. Once the requirements have been written, they are re-read, analyzed against the parent stakeholder requirements, to ensure that they are of adequate depth and detail, and then we move on. Further detail or breakdown occurs if required. The requirements are then allocated to one of the locations within the requirements breakdown structure. We look at the requirements breakdown structure and work out where, within that structure, the requirement best fits. If it turns out that the requirement could reside in more than one location within the structure, that's okay. We make a decision, record it once, and then refer to it from the other locations. Duplicating and repeating requirements in the same document is considered bad practice and will result in potential conflict and confusion in the future, especially if the requirements change. We now have our requirements in a structured form that we're going to call a system requirements specification, or an SyRS. This may be a physical document, but it may also be a spreadsheet or it might be in some other form like a structured or populated database. It could even be in the form of a model of the desired system, that's able to illustrate the system requirements via simulation. There are plenty of reference sources out there to explain what structure and content should be used for this level of specification. It's form is not as important as it's existence. It's only a draft at the moment because we're likely to categorize our requirements as mandatory, important or desirable. For example we might have a functional requirement associated with detection range for our burglar alarm made we might have three levels of performance. We might say that the alarm needs to be able to detect an 80 kilo human, under certain environmental conditions from ten meters mandatory, 12 meters important, and 15 meters desirable. This allows us some flexibility in expressing our requirements and it also allows us to assess the value of different solutions when we look at possible solutions in the next stage. Whilst this concept helps us at the moment, we will not leave those levels in the final specification. We will end up replacing those levels with an agreed level that the selected solution claims to be able to achieve. We've been doing a lot of work in order to develop and document the system level requirements. As discussed earlier, it seems like common sense that we would review our work before proceeding and this is certainly the case with our requirements. Unimaginatively, we are going to call these reviews system requirement reviews or SRR's. Sometimes if we're dealing with a straightforward situation, we might only conduct a single SRR for our system, but, in all likelihood a single review just might be sufficient. We'll probably conduct a series of reviews in a work-review-rework cycle, until we're happy with our set of requirements. This idea of a series of reviews leading to a complete and agreed set of requirements, is illustrated in your slide. Either way, once we've completed our SRR process, we're ready to move on to system level synthesis. The draft system requirements spec is sent out to potential solution providers. These might be external organizations or they might be in house solution providers. These providers will review the specification and try to match it to what they can provide in the form of a solution. They also note any differences between their potential offer, and the draft system requirement spec. Differences might be discrepancies or non-compliances, or there might be additional functions, or enhanced performance levels that the proposed solution can offer. In most cases, solution providers will propose a revision of the draft system requirement spec to make it better aligned with their proposed solution,. Potential solution providers also advice the acquirer of the cost and schedule associated with their solution, along with the proposed revision to the system requirements spec. The acquirer will consider all of these offers from different suppliers before making a decision about which way theyâre going to proceed. It's normal to conduct a period of negotiation and offer definition with the preferred supplier, so that both the acquirer and supplier are very clear about what is required and what is being offered including how the system is going to be verified by the customer prior to acceptance. The system requirement spec will be a very important part of these discussions, and by the end of the discussions that specification needs to be refined and agreed and needs unambiguously define the what, how, well, and so on of the proposed solution. Once we have a solid understanding of our requirements via the system requirements pick, and we've selected and negotiated a preferred solution via system level synthesis, we conduct a system level design review to confirm that we are ready to move on to preliminary design. Not surprisingly, we're going to call this review a system design review, or SDR. During SDR, we will investigate the proposed solution, and the refined system requirement specification. Within the refined system requirement specification we're going to have a look at the traceability back to the stakeholder requirement spec, and the planning that's being put in place to execute and manage the technical program. Like all of our design reviews, we need to run the system design review like a professional technical meeting. This means that we need to establish an agenda, nominate a chair person anda secretary, take minutes, take action items and then follow up on those action items, after the meeting. Once complete to the satisfaction of the acquirer, we're ready to move on to the next stage of the system's engineering process.
