Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chapter Five: Requirements



  • Sommerville makes the distinction between functional and non-functional requirements? Clearly define these terms and give one or two examples of each type of requirement.

Software system requirements are sometimes broken up into functional and non functional requirements. Sommerville states their definitions as follows, although he also says that they are not as clear cut as these definitions would suggest. In order to understand the differences between the two requirements, we will use an example of a database.

Functional requirements are the statements that state how the system should react to input, what the system should provide, and how the system should react in different situations. Functional requirements may be expressed in different ways in order to describe the functionality that the service provides. Functional requirements depend on the type of software which is being developed, the expected users of the software and the type of system which is being developed. In order for these requirements to be understood, Sommerville states that it is important that functional requirementes be both complete and consistent, even though this tends to be difficult in larger systems where there will always be ambiguity and different viewpoints. For a database, some functional requirements would be which users can access what information, what happens when a database does not respond, and what the system will do if more than one user is trying to access the database at the same time.

Non functional requirements, on the other hand, are the constraints on the function that are offered by the system; these include timing constraints, standards, and development processes. These requirements are not directly concerned with the functionality of the system but relate to system properties, such as reliabilty, response time, and storage, and define the constraints on the system. Non-functional requirements deal with the sytem as a whole rather than certain aspects of it; as a result if a non-functional requirement is not met, the whole system may be unusable. Non functional requirements also arise through the needs of the user, budget issues, policies, and/or external factors. Sommerville classifies non functional requirements into three categories: product, organizational, and external requirements. Product requirements specify product behavior; for the database, a product requirement would be how big or fastthe database will be. Organizational requirements are the policies and procedures in the customer's and developer's organization; for the database, this would be which language to create the database with. External requirements are those that are derived from factors not relevant to the system or the development; for the database this requirements would be ethical requirements or privacy requirements regarding the information on the database.
Noosh Moussavi

Functional Requirements statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. they describe the functionality or services that the system is expected to provide.
example: for bank software, the requirement that no two users have the same account-ID. Requiring a password to access information off of a web-site.

Non-Functional Requirements constraints on the services or functions offered by the system. those requirements which are not directly concerned with the specific functions delivered by the system. example: in a database, locking a record that is being edited.

Deb Wright

Other students have suggested that non-functional requirements are related to performance, reliability, and interoperability. How is the locking of a record in a database related to this? I do not really understand your example of a non-functional requirement. In your banking example, could you cite things like Matt Rummel provided? Greg


Functional requirements provide a specification for the services that the software is to provide for the user. Functional requirements include how the system will react to given set of inputs, what levels of data access should be provided for each user, and what type of interface is utilized. As an example of functional requirements, let us consider the software system for a bank. Some of the functional requirements would be the following provisions: if the customer has a negative balance, do not allow them to cash checks on their account, if a transaction is not accepted on the main database for all branches, return an error box, and to provide different views of branch totals for managers and employees. Sommerville states that all functional requirements should be "complete and consistent." This means that one must be careful when making a list to functional requirements to make sure that the implementation of some requirements does not infringe upon others. For example, once again consider our bank example. Let one requirements be to make the interface for teller transactions such that operations can be formed quickly, and another is to have a high level of management supervision. The management requirement would perhaps be utilized by requiring supervisor over-rides for certain operations. This requirement, however, would conflict with the requirement of quick teller transactions, since they must go get a manager every time they attempt such a transaction. Clearly, one must decided which functional requirements have precedence in particular cases and make decisions accordingly

(Note: I worked at a bank this past summer and had the "pleasure" of being there during the transition period from an older software system to a new one. I often thought some of the functional requirements in the new system actually were a step backwards from the old system, hence my examples).

Non-functional requirements are those that are more concerned with the technical nature of the system. A non-functional requirement is how the system implements the various defined functional requirements. These requirements have to do with the efficiency consideration, reliability, portability, and CPU usage. In our bank example, we could say that a functional requirement would be the connection protocol used to connect to the central banking system, the type of database used in the central banking system, and the speed of the connection. A more familiar example of a non-functional requirement would be a computer science instructor asking his students to use a visitor design pattern in a program. (Cruel as it may be, there have been documented cases of such things). Sommerville notes that functional requirements usually pertain to the bigger picture of the software system: If a non-functional requirement does not work correctly it is often not just one component of the software that will malfunction but the system as a whole.

Matt Rummel

If I actually required you to use the Visitor design pattern on the long-term project, I believe that it would violate the what/how principle. Hopefully, I will not write a requirements document that makes and statements about the design of the software system. For our past laboratory, I required the usage of the Visitor design pattern to equip you for future situations where the Visitor might be applicable. Greg


  • Sommerville discusses several different types of notations for requirements specification. Which approach do you think would be most useful for the specificiation of a safety-critical system? What technique would you feel most comfortable using?

System requirements specification are more detailed descriptions of what the user determines are the requirements for the system. Often times, these specifications state what the system should do and not how it should be implemented. Also system requirements can include different models of the system such as a data flow model. Sommerville states several notations for requirements specifications which includes structured natural language, design description languages, graphical notations, and mathematical specifications. Structured natural language is a form of natural language for writing system requirements. Design description languages use a programming language but with more abstract features to specify the requirements of the system. Graphical notation is used to define the functional requirements of the system. Mathematical specifications are based on mathematical concepts such as sets and finite state machines.

The list of requirements specifications are listed from most ambiguous to least ambiguous. Structured natural languages are prone to misunderstandings whereas mathematical specifications reduce the arguments between customer and contractor about system functionality. Thus for a ssfety critical system, it would be better to use something such as the design description languages or the mathematical specifications. Sommerville does state that these notations are harder for the customer or non-contractor to understand however this becomes important in ensuring that only those who should see the specifications of the system see it and understand it. Personally, I would feel most comfortable using the design description languages since in most cases they use a programming language in abstract form. This would make it easier to determine the layout of the system and establish the requirements specifications.
Noosh Moussavi

If you are using a design description language, do you feel that it might enable you to violate the what/how principle? For the majority of the software systems that I have written in the past, I seem to prefer rigorous natural language requirements. Personally, I have found a program description language to be too close to a general purpose programming language. Greg

For the specification for a saftey-critical system, i believe the best notation would be the mathmatical specification, or the design description notation. the mathmatical specification reduces the arguments between client and designer, using mathmatical proofs and sets to unsure the program will work. the design description languages use programming languages with the addition of abstract features to specify the requirements and defining an operational model of the system, and is easier to understand by the client. I would be more comfortable usingthe design description languages, as they use programming languages and would be easier to understand and explain to customers.
Deb Wright

The issue of choosing a notation for safety-critical systems, is not an easy decision to make. My initial reaction was that mathematical specification was the best method available. This was based on my thinking that the less a notation utilized components of spoken languages the better. Spoken language can at times be ambiguous and easily misinterpreted. This is why I feel that structured natural language is not the way to go for notation – an easily misinterpreted statement can be placed in a uniform template. Mathematics on the other hand is very concrete. When a requirement is based on a finite-state machine, it is leaves little room for misinterpretation. Pondering this issue a little farther however, I began to see some problems with mathematical interpretation. Software systems are very complex, and to describe all requirements using mathematics would create a very complicated notation, hard to both read and write. I therefore concluded that the best method would be design description languages. This notation I see as being the best of both worlds: you have structures representing operations like in mathematics, yet it is easier to read, write and understand. Furthermore, one does not have the ambiguity of written language when this notation is used. I think that ultimately, this notation is the one that I feel the most comfortable with and would likely use on a safety critical system.

Matt Rummel

I have found it interested that everyone seemed to argue against the usage of structured natural language – I expected exactly the opposite response! Let me then ask one further question: for the long-term project, what should I use to express the requirements of our software system? Greg


Link to this Page