VU Help • House Banner
VU Help
Virtual University Students - Assignments, Solved Papers, GDB & Exam Help
Student Help Forum • Collaborative • Free Support
Posts: 323
Threads: 241
Joined: Oct 2012
[h=1][/h]
CS504 Software Engineering - I Assignments No.01 Solutions Fall 2014
Question No. 1 5 Marks
What are the business requirements of given “Intelligent Aircraft System? Your answer should not exceed more
than three lines.
Question No. 2 5 Marks
List down the functional requirements of given “Intelligent Aircraft System”
.Question No. 3 5 Marks
List down the non-functional requirements of given “Intelligent Aircraft System”.
Note:
Ø Assignment should be in your own wordings not copied from net, handouts or books.
Ø Your answer should be “to the point”.
Ø We wish you very best of luck for your Assignment.
Posts: 5,456
Threads: 5,349
Joined: Dec 2011
In software engineering (and systems engineering), a functional requirement defines a function of a system and its components. A function is described as a set of inputs, the behavior, and outputs (see also software).
Posts: 5,456
Threads: 5,349
Joined: Dec 2011
In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
Posts: 607
Threads: 553
Joined: Dec 2013
Intelligent aircraft system” must be a fast real time system, which includes various dimensions ranging from
geographic localization towards target vision in any kind of situation e.g. Thunderstorm, Rain, Heavy, Clouds,
Foggy Weather, Darkness of Night etc. The system is successful, if equipped with strong communication channel
to its remote control tower and other peer aircrafts.
The aircraft can travel to long distance in minimum fuel consumption and in minimum time, so to avoid decision
making due to time dilation. The intelligent system, if made equipped with supervised learning to fill the learning
repository at such level, so that in 100th
or 1000th
iteration in terms of decision making involving dangerous turns
over the hills or targeting blurred object, so that to get maximum chance of accuracy.
The transition from supervised learning mode towards unsupervised learning mode leads the aircraft system more
functional in terms of independent decision making. The fuel, body, location, mileage, missile and weather are
the primary attributes to consider. The aim of intelligent aircraft system is to reach to remote locations and took
over the proceeding’s like war situation, flood situation, earthquake situation etc. According to the feeding or
reactive element provided to the system.
Levels of Software Requirements
Software requirements are defined at various levels of detail and granularity. Requirements at different level of detail also mean to serve different purposes. We first look at these different levels and then will try to elaborate the difference between these with the help of different examples.
1. Business Requirements:
These are used to state the high-level business objective of the organization or customer requesting the system or product. They are used to document main system features and functionalities without going into their nitty-gritty details. They are captured in a document describing the project vision and scope.
2. User Requirements:
User requirements add further detail to the business requirements. They are called user requirements because they are written from a user’s perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements. They are captured in the requirement definition document.
3. Functional Requirements:
The next level of detail comes in the form of what is called functional requirements. They bring-in the system’s view and define from the system’s perspective the software functionality the developers must build into the product to enable users to accomplish their tasks stated in the user requirements - thereby satisfying the business requirements.
4. Non-Functional Requirements
In the last section we defined a software requirement as a document that describes all the services provided by the system along with the constraints under which it must operate. That is, the requirement document should not only describe the functionality needed and provided by the system, but it must also specify the constraints under which it must operate. Constraints are restrictions that are placed on the choices available to the developer for design and construction of the software product.
These kinds of requirements are call Non-functional requirements. These are used to describe eternal system interfaces, design and implementation constraints, quality and performance attributes. These also include regulations, standards and contracts to which the product must conform.
Non-functional requirement play a significant role in the development of the system. If not captured properly, the system may not fulfill some of the basic business needs. If proper care is not taken, the system may collapse. They dictate how the system architecture and framework. As an example of non-functional requirements, we can require software to run on Sun Solaris Platform. Now it is clear that if this requirement was not captured initially and the entire set of functionality was built to run on Windows, the system would be useless for the client. It can also be easily seen that this requirement would have an impact on the basic system architecture while the functionality does not change.
While writing these requirements, it must always be kept in mind that all functional requirements must derive from user requirements, which must themselves be aligned with business requirements. It must also be remembered that during the requirement engineering process we are in the definition phase of the software development where the focus is on what and not how. Therefore, requirements must not include design or implementation details and the focus should always remain on what to build and not how to build.
Example:
Let us now look at an example to understand the difference between these different types of requirements.
Let us assume that we have a word-processing system that does not have a spell checker. In order to be able to sell the product, it is determined that it must have a spell checker. Hence the business requirement could be stated as: user will be able to correct spelling errors in a document efficiently. Hence, the Spell checker will be included as a feature in the product.
In the next step we need to describe what tasks must be included to accomplish the above-mentioned business requirement. The resulting user requirement could be as follows: finding spelling errors in the document and decide whether to replace each misspelled word with the one chosen from a list of suggested words. It is important to note that this requirement is written from a user’s perspective.
After documenting the user’s perspective in the form of user requirements, the system’s perspective: what is the functionality provided by the system and how will it help the user to accomplish these tasks. Viewed from this angle, the functional requirement for the same user requirement could be written as follows: the spell checker will find and highlight misspelled words. It will then display a dialog box with suggested replacements. The user will be allowed to select from the list of suggested replacements. Upon selection it will replace the misspelled word with the selected word. It will also allow the user to make global replacements.
Finally, a non-functional requirement of the system could require that it must be integrated into the existing word-processor that runs on windows platform.
Levels of Software Requirements
Software requirements are defined at various levels of detail and granularity. Requirements at different level of detail also mean to serve different purposes. We first look at these different levels and then will try to elaborate the difference between these with the help of different examples.
1. Business Requirements:
These are used to state the high-level business objective of the organization or customer requesting the system or product. They are used to document main system features and functionalities without going into their nitty-gritty details. They are captured in a document describing the project vision and scope.
2. User Requirements:
User requirements add further detail to the business requirements. They are called user requirements because they are written from a user’s perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements. They are captured in the requirement definition document.
3. Functional Requirements:
The next level of detail comes in the form of what is called functional requirements. They bring-in the system’s view and define from the system’s perspective the software functionality the developers must build into the product to enable users to accomplish their tasks stated in the user requirements - thereby satisfying the business requirements.
4. Non-Functional Requirements
In the last section we defined a software requirement as a document that describes all the services provided by the system along with the constraints under which it must operate. That is, the requirement document should not only describe the functionality needed and provided by the system, but it must also specify the constraints under which it must operate. Constraints are restrictions that are placed on the choices available to the developer for design and construction of the software product.
These kinds of requirements are call Non-functional requirements. These are used to describe eternal system interfaces, design and implementation constraints, quality and performance attributes. These also include regulations, standards and contracts to which the product must conform.
Non-functional requirement play a significant role in the development of the system. If not captured properly, the system may not fulfill some of the basic business needs. If proper care is not taken, the system may collapse. They dictate how the system architecture and framework. As an example of non-functional requirements, we can require software to run on Sun Solaris Platform. Now it is clear that if this requirement was not captured initially and the entire set of functionality was built to run on Windows, the system would be useless for the client. It can also be easily seen that this requirement would have an impact on the basic system architecture while the functionality does not change.
While writing these requirements, it must always be kept in mind that all functional requirements must derive from user requirements, which must themselves be aligned with business requirements. It must also be remembered that during the requirement engineering process we are in the definition phase of the software development where the focus is on what and not how. Therefore, requirements must not include design or implementation details and the focus should always remain on what to build and not how to build.
Example:
Let us now look at an example to understand the difference between these different types of requirements.
Let us assume that we have a word-processing system that does not have a spell checker. In order to be able to sell the product, it is determined that it must have a spell checker. Hence the business requirement could be stated as: user will be able to correct spelling errors in a document efficiently. Hence, the Spell checker will be included as a feature in the product.
In the next step we need to describe what tasks must be included to accomplish the above-mentioned business requirement. The resulting user requirement could be as follows: finding spelling errors in the document and decide whether to replace each misspelled word with the one chosen from a list of suggested words. It is important to note that this requirement is written from a user’s perspective.
After documenting the user’s perspective in the form of user requirements, the system’s perspective: what is the functionality provided by the system and how will it help the user to accomplish these tasks. Viewed from this angle, the functional requirement for the same user requirement could be written as follows: the spell checker will find and highlight misspelled words. It will then display a dialog box with suggested replacements. The user will be allowed to select from the list of suggested replacements. Upon selection it will replace the misspelled word with the selected word. It will also allow the user to make global replacements.
Finally, a non-functional requirement of the system could require that it must be integrated into the existing word-processor that runs on windows platform.
|
