#SRS #constraints [[00 - Outcome 2 - Analysis and Design#6. Constraints constraints that influence solution development, including|U3-AOS2-KK6]] A **constraint** in the context of a **Software Requirements Specification (SRS) document** is a **limitation** or **restriction** placed upon the design, implementation, or operation of the software system. These constraints define the boundaries within which the development team must operate, ensuring the final product is viable, acceptable, and successful. --- ## Key Types of Constraints Constraints can stem from various sources and are typically categorised as follows: ### Economic Constraints - These relate to the **financial limits** of the project. - **Example:** A **fixed budget** for development, dictating the maximum cost of hardware, software licenses, or personnel salaries. It directly impacts the **scope** and **quality** of the features that can be implemented. ### Technical Constraints - These are limitations imposed by the **technology** chosen or the **operational environment**. - **Example:** The system must integrate with an **existing legacy database**, requiring the use of specific APIs or programming languages. Other examples include performance requirements (e.g., must respond within 2 seconds) or limitations on **available hardware** (e.g., minimum RAM on user devices). **What is NOT technical constraint** - The developers technical knowledge or ability ### Social Constraints - These constraints arise from the **users' needs**, **organizational culture**, or **ethical considerations**. They often relate to **usability** and **acceptance**. - **Example:** The system's user interface must be designed to be accessible to users with visual impairments (complying with **accessibility standards**), or the workflow must strictly adhere to the company's internal **data handling protocols**. ### Legal Constraints - **Legal Constraints:** These are mandatory restrictions imposed by **laws**, **regulations**, or **industry standards**. Failure to comply can result in severe penalties. - **Example:** The software must comply with the **Privacy Act 1968** regarding the storage and processing of user data, or it must adhere to specific **industry security standards** like Health Records Act 2001 for healthcare applications. --- In essence, constraints are **non-functional requirements** that act as rules of the game. They ensure that the software not only _does_ what it's supposed to do (functional requirements) but also _meets all necessary external conditions_ to be considered a viable and successful solution. ## Exam Questions ![[2023 Exam#Question 8]] It is very important to understand the constraints that are placed upon a solution. Without an understanding of the constraints, the success of the solution may be in jeopardy. ### Economic factors Probably the most common and obvious constraint is that of cost (economic). This will vary quite a bit from situation to situation and will depend on the size of the organisation, the budget and the scale of the project. Often when reflecting on the cost of a project, software developers will focus on the resources required, whereas the main cost is generally time. Development time is valuable and it may be that the time frame is set by the production milestones. While this is a factor, the cost of having a software developer or a project team working on a solution over a period of time, may mean that the overall cost of a project is much more expensive that an organisation realises. This is especially true when organisations are using their own software developers who are on staff, as they aren’t considering what it would cost to employ someone on a contract basis specifically to create the solution. When employing a software developer on a contract basis, the cost of the software developer’s time is transparent, and may cause an organisation to reconsider their options or their budget. ### Technical factors Security features may be needed or may be part of the existing infrastructure and need to be catered for. Compatibility with existing hardware and software may also be a factor as well as the speed of processing required (or available) and the capacity of the existing system. The solution may need to be developed for multiple platforms as well. Let’s expand upon some of these briefly. #### Technical factors: speed of processing The speed of processing required of a system will vary depending on what the system has been built to do – an air traffic routing system will certainly need to process a large amount of data quickly as opposed to an online diamond purchasing website. The speed of processing of a system is often exhibited in its response rate. The response rate is a measure of how long it takes for certain actions within the system to be completed. If the response rate is too long, users may get frustrated with the system and will view the software product negatively. Similarly, a low response rate could result in loss of customers and loss of money, as completing a task may take longer than it should. Speed of processing is often measured in IPS (instructions per second) which in turn becomes MIPS (million instructions per second) and GIPS (giga instructions per second). The number of instructions that a system can process is often not the best way to represent its speed, as the speed can be significantly influenced by factors such as the CPU architecture and memory structure. #### Technical factors: capacity The capacity of the current information system is a significant constraint on any proposed software development. Capacity can include simple factors such as the amount of available hard drive and/or network storage or the amount of memory within the computer systems that will use the software solution. The network infrastructure will place a limit on the amount of data that can be transferred simultaneously. It may also place a functional or physical limit on the number of people that can use the software solution at the same time. #### Technical factors: availability of equipment The availability of equipment may be a constraint in a number of ways. It might be the case that the software solution is being developed for an information system that is being upgraded and does not have the required hardware and software components as yet. It might also be the case that the current hardware and software will not be upgraded at all to cater for the new solution, so the software developer must work within the reasonable limits of their capacity. This leads into the next technical constraint that needs to be considered – compatibility. Technical factors: compatibility As with the previous constraint, a new software solution will often need to work within the bounds of the existing system. This includes being compatible with the existing components. On a base level, a software developer needs to be aware of the operating system that the existing system is utilising. On top of this, a software solution will need to send data to and from related systems and databases and will need to be compatible with the file formats that these systems use. The specifications of the devices within the system will need to be catered for so that the software solution runs in an optimal fashion when being used by these devices. Technical factors: security An organisation may have specific requirements in terms of security for the new software solution. Features such as encryption may need to be included and data may need to be stored and accessed from secure network servers within the building or off-site. A software solution may need to be able to be integrated with a SSO (single sign on), which essentially means that a user can access the system once they have logged in to the main portal of the organisation. Social factors Constraints on the solution of the ‘social’ type can include the level of expertise of users, availability of technical support staff, the time available to develop the solution and the availability of equipment. There also may be users in the system who have special needs such as sight or hearing impairment or a disability. Legal requirements Without discussing the specifics of the legislation concerning copyright and privacy, it is easy to comprehend how legal requirements within organisations act as a constraint on a software solution. For example, an organisation’s privacy requirements may dictate that a software developer needs to protect the data within a software solution and include security features that prevent unauthorised access. This will undoubtedly take time and add to the cost of the development. Chapter 9 explains the relevant legislation in detail and discusses some of the issues surrounding it. An organisation also needs to consider the ownership of key components. Now that we are in the era of cloud computing, key software solutions may well be located off-site or indeed in another country. It is important that an organisation has a clear agreement with the software solution provider that ensures the ownership of their data remains with them. Usability factors Another constraint on the software solution is usefulness. This is not to be confused with the ease of use of a solution. Usability factors: usefulness Usefulness is the measure of the ability of something to satisfy need. As a constraint, this may be the requirement from users that a new software solution performs in a particular way or offers a number of core features. This may be a constraint as a direct result of an evaluation of the previous system that may have identified some specific concerns that users have. Usability factors: ease of use The ease of use of a proposed software solution is a constraint as it may place some specific requirements on the development of the user interface. There may be aspects of the development that need to concentrate on the function of the new system when used on the types of devices that users have. There may have been difficulties in the past with the number of steps or complexity of tasks within the software. There may have also been issues with the ease with which data was entered and validated. Identifying the constraints on the solution is the second activity listed under analysis in the PSM.