In the last lecture, we have mentioned that no matter which software development process that you're using for your project, there are five important activities that you have to perform within your project. They are; requirements capture, analysis, design, implementation, and testing. In this lecture, we focus on system requirements capture. These are the learning objectives of this lecture. After this lecture, you will understand what is requirements capture and its role in software development process. You'll also understand why requirements capture is both important and difficult. You will also know the major activities that take place during requirements capture. You will also learn how to use UML to model a system's data and also functional requirements using class diagram and also use case diagram. Finally, you'll understand the importance of validating system requirements. This lecture is going to be an overview about system requirements capture. We will also talk about how to use class diagram to capture all that data requirements of a software system and we are talking about domain modeling. In requirements capture, we focus on inception and elaboration. That means we try to collect all the requirements from our client and also from our application domain, and then double-check whether the project is feasible or not. If it's feasible, then we go ahead and do the project. If it's not feasible, then we may have to stop and tell our client that the project is not feasible and we have to stop. That's why we do it at the very beginning of the project because we have to get all the requirements and understand exactly what we have to do within the project before we proceed to construction and also transition. What is a requirement? If you go to the Internet, you may find different definitions from different dictionary or from Wikipedia. In this course, we define a requirements as a feature that the system must have or a constrain that you have to satisfy in order for your software system to be accepted by your client. The requirement can be ranged from a high-level abstract statement of a surface. For example, a problem statement or a system constrained to a detailed mathematical specification in terms of, for example, a formula or a diagram. There are different types of requirements. Some of them are written mainly for clients, for example, user requirements. They are specified in natural language possibly with diagrams or the surfaces the system provides and its operational constraints. If we're talking about statements in natural language, again, we're talking about a problem statement. Possibly, you may include some diagrams in your statement. That's mainly written for our clients. Also, we have system requirements, which is a structural document setting out detailed description of the system functionalities, surfaces, and also operational constraints. It defines what should be implemented and it's being treated as part of a contract between the client and the developer. It's written for different stakeholders, for example, your clients and also the developers. One major purpose of requirements captures is that it's going to specify the behavior of the final software system. In requirements capture, we have to learn about the problem that needs a solution. Also specify the requires features and also constraints of the system in a way that both decline and also the user can understand and also can approve. Remember that when we try to capture all the requirements, we try to specify the problem, but not the solution. Not that this side that we're going to use for implementation. We are just trying to capture all the requirements, that's it. The result of requirements capture is going to help in project planning because you know exactly what you have to do within your project. Then it's going to help you plan or plan out your project. Some of you may ask, why do we need to capture and also document requirements? Why do we have to come up with all the documentations before we actually go ahead and perform implementation? The reason is that our brain is optimistic. Think about night dream. On the next day you think that you remember everything but after a few days, you forget about all the details. The same thing is going to happen in software development. You may think that you remember every single detail in your project but during development or during implementation, you may find that you forget many important things or many important details within your project. That's why you need to come up with some documentation to capture and also to document all the requirements in order to reduce errors. Believe me or not, many of the software projects, they fail because of incomplete requirements or lack of user involvement. Just because you don't know exactly what you have to do within your project, you don't understand what are the requirements within the project and that may lead to project failure. That's why I say here that failure to do requirements capture, well, at the beginning of the project is a major cause of software development failures or problems. This is a little diagram showing the cost for fixing some defects at different stage of your project, and you can see that if you fix a defect early, it's going to be key. If you fix it late in your project, it's going to be very costly. That's why we want to capture all the requirements correctly right at the beginning of the project. Because we don't want to fix some defects that are related to requirements late into project, which is going to be costly. Good requirements capture is going to help reduce the cost of software development. Why requirements capture is so difficult? Just because from this little story, you can see that sometimes even the client, they don't know exactly what they want. As a software engineer, one important thing that you have to do is to confer the vague requirements from the client into something that's more precise and something that you can use for development. Notice that requirements capture requires the collaboration of several stakeholders, usually from different backgrounds. Just because you have so many stakeholders within your project, then you have to fill out the knowledge gap between different stakeholders. The challenge here is how to bridge the knowledge gap. There are a few things that you have to do as a software engineer. First thing is that you have to learn about the application domain and also discover all the requirements from the application domain. Then you have to transform the vague ideas from your client into something that's going to be more precise, and also choosing an appropriate representation for specifying requirements. In this course, we are going to use class diagram and also use-case diagram to represent requirements. As a software engineer, sometimes you may even have to educate your client or users. For system requirements capture, we have to build different models. For example, we have to build a domain model to capture all the data requirements. We also have to build a use-case model to capture all the functional requirements. Also you have to capture all the nonfunctional requirements and then eventually validate all the system requirements. In this lecture, we focus on domain modeling. That means we're going to use a class diagram to capture all the data requirements. Again, at this stage, we focus on simply capturing requirements and we ignore the implementation details. What we're going to do is that given a problem statement, we try to capture all the requirements from the problem statement and then come up with a class diagram to represent all the important things that we need to keep track within the software system. That's what we mean by data requirements. All the important things that we have to keep track within the software system. This are the activities that we have to perform when we capture requirements. First, we have to understand the application domain and then identify user needs. After that, you have to determine the potential risk of developing the system. Then you have to capture the system requirements in terms of a domain model, a use-case model, and also nonfunctional requirements. Then finally, you have to make sure that the system requirements that you have captured, they are correct and also complete. Correct means you have captured all the requirements correctly, and complete means you have captured all the important requirements. In this course, we focus on capturing the system requirements. It's important that you come up with a system requirements specification right at the beginning of the project. The system requirements specification, SRS documents the system requirements and is an official statement of what is required of the software system. It should include both a definition of user requirements and also specification of system requirements using different models. Notice that it is not a design document. Again, the models, we are not using it for implementation. We just specify what the system should do. We've to think about how we actually implement those features. Even though many agile methods they may argue that producing an SRS is a waste of time because requirement they may change quickly. However, even if you're using agile methods, for example, Scrum, still you have to capture requirements in terms of a product backlog. That's why it's still important that you learn how to capture all the requirements from the application domain. There are different ways of writing a SRS. You may use natural language in terms of a problem statement or structured natural language using a template, or using graphical notations, or using some design description language, something like crucial code or a mathematical specifications. In this course, we focus on drawing diagrams. That's why we say graphical notations. Also using some template for writing SRS.
