Learn something new every day
More Info... by email
A typical computer application includes a composite of software, hardware, and network components. System requirement specification (SyRS) is a detailed outline of the requirements necessary to create a complete system. These requirements are documented in an effort to define the complete functionality, availability, performance, and security needs of a system.
The Institute of Electrical and Electronics Engineers (IEEE) is the largest technical society dedicated to standards in the electronic and computer field. IEEE has created a set of standard procedures on how a system requirement specification should be documented. This documentation includes guidance on the creation, organization, and modifications of the system's requirements.
The creation of a SyRS is typically completed by a business analyst. The business analyst is a professional who is responsible for converting business jargon into technical solutions. She is the liaison between the business and the technical community. A good business analyst is an effective communicator who can articulate business needs to a technical team.
There are many benefits in following the best practice guidelines for a system requirement specification. The requirements specification is the foundation of the architecture, design, and implementation that will be built. These requirements are used to determine the level of effort needed to complete a project. Bad requirements are comparable to a bad foundation for a building, which will always lead to a failed implementation.
All systems have performance requirements that should be documented within the system requirement specification. These requirements define the response time, availability, and productivity of a system on specific tasks. As an example, an insurance company could have a requirement to process 100,000 insurance claims per day. This requirements would be considered a performance requirement.
A functional requirement is a characteristic of a system based on specific business processes. A functional requirement could be as simple as rules for how an application should create and save data in the system. For example, a business could require that all persons must have an address before the system will save the data to a storage device. This functional requirement would be documented within the requirements specification.
The security requirements are often the most important aspects of a system. These requirements are documented to outline how data will be accessed and the what policies should be used for encrypting the data within the application. With the ongoing threat of hackers and online predators, cyber security has become an increasingly important requirement for most computer systems.
@allenJo - I’m not a programmer myself, but I’ve worked with them and with end users as well.
Based on my experience, I strongly believe that you can never spend too much time hammering out IT requirements. Some things should seem obvious – but the point of software development is to give the end user an experience that she wants, not what the IT group thinks is cool or the latest technology.
I’ve seen too much over-engineering by IT folks (some, not all, to be fair) and miscommunication as well. End users don’t need bells and whistles.
They want the software to do a certain thing, and do it well. Sometimes the end users bring past experiences to the table, like an old DOS program which did exactly what they wanted.
I realize we don’t develop in DOS anymore, but we don’t need slick interfaces either. It just needs to do what the user expects.
In the last company I worked for the engineering and IT groups both worked with a business analyst to get things done.
For example the engineering group would often have software requests. Sometimes they wanted updates to the company’s departmental intranet, or they wanted a complete reporting system built from the ground up to access information in a data warehouse.
We called upon the business analyst to communicate our plain English requests into “computerese” that the IT people could understand.
Actually the business analyst did more than just translate our request, she drew up a requirements analysis. She hammered those requirements down with persistence and a whole lot of precision, making sure she understood exactly what we wanted, so that the product met with our satisfaction.
She also worked out a timetable and pegged milestones along the way, to ensure that IT was on track. She rarely missed a beat, and we were happy with the results.