Data requirements

- [Instructor] When a software system works, it is data that flows from input to output, and to storage devices. With the internet and software becoming ubiquitous in all devices, the variety and volume of data has increased exponentially. Capturing the characteristics of this data is critical as understanding the functional, and non-functional requirements of a system. Let us take a look at some of the key characteristics of data that need to be specified. One way to understand data is to look at it from the system's functional and non-functional point of view. The functional point of view focuses on the internal characteristics of the data, or its meaning. The non-functional view focuses on the data structure, format, speed, and other external characteristics that often depend on the source and the destination of data. For example, if your developing a financial accounting application, you cannot understand its functionality unless you understand terms such as debit, credit, assets, liabilities, balance sheet, and income statement. You need to define each data element, what it signifies, it's data type, format, length, range, and so on. The data content, or its meaning, represents domain knowledge. This domain knowledge about domain specific terms and their meaning is captured in a data dictionary. A data dictionary is a collection of detailed information about the data entities used in an application. For example, in our Uniker system, to make sure that every one on the team has the same correct understanding of these terms, the team has to create a data dictionary which may have the terms shown here. A sample data dictionary will look something like this. Depending on the complexity of data, you may have many more columns to make the data dictionary comprehensive. A data dictionary should be developed as a shared resource within the team. It can be in a simple document, a spreadsheet, a wiki, or some kind of database. Whichever form you choose, it should be constantly updated as new requirements are developed, and the team acquires new understanding about different terms. From the data dictionary you can then move on to a very important aspect of data that relates to its access. You need to map which actor has what kind of access to various data elements. One way to capture this is to use CRUD Matrix. CRUD is an acronym for Create, Read, Update, Delete. Since actors initiate use cases by specifying what specific access is required for a use case, you can add and define which actor requires what kind of access to data. CRUD Matrix also helps add and define any missing requirements. For example, here, we can see that the calendar entity is being read, but the use case for creating the calendar is not add and and defined. And therefore it points to a missing functionality. As data flows from input to output, the process which it goes through can be modeled using data flow diagrams, or DFD's. DFD's have been around for a very long time and are a very powerful way to capture data entities, functionalities, and data storage points. They can be drawn at various levels of abstraction. Starting with a high-level functionality, and then zooming into each of the bubbles to define intricate data flows. If you have learned about database design, you should be familiar with entity relationship diagrams, or ERD's. ERD's can also be used as a requirement analysis tool just to capture the relationship among various data entities without worrying about databases. This would mostly be applicable if your data is of a relational kind. Apart from these four techniques for data analysis and specification, there are other data modeling techniques using object-orientated system designs such as a Statechart diagram. You can learn more about them in my course on UML available in the Lydon library. These techniques are very important to perform functional requirement analysis in an effective manner. All techniques discussed so far, focus on the functional aspects of the data as they focused on its meaning. When looking from the non-functional point of view, the focus shifts from the meaning to structure of the data. Our system received incoming data from various sources and often it cannot dictate the structural properties of this incoming data. Similarly, the structure of outgoing data is also often defined by those external systems to where the data is headed. This makes it critical to understand and clearly define, various structural properties of this data. When looking at Source, you need to think about what is the source device? If the data is coming through the internet, what encoding and language does it have? For audio or video files, knowing about the encoding and file formats becomes very critical. Factors such as format, integrity, and consistency, help determine if any ETL that has extract, transform, load functionality needs to be developed. Volume and volatility directly impact the performance of the data flow and its read/write storage. Many of these Source properties such as encoding, format, volume and volatility, apply to Destination data as well. One additional property which is more of a functional than non-functional, is the kind of reports to be produced by the system. Users want to see outputs in various formats and presentation styles on different kinds of devices. When eliciting requirements you need to understand their expectations such as latency or currency, that is, how quickly they want a report, and often it should be updated. What should be the layout? And whether the report should be interactive, with drill-down feature or just static. Since output is what will determine whether your user needs are met or not, capturing these requirements effectively becomes very critical.