Functional and Non-functional requirements

I. Types of Requirements :

A. What is functional requirements ?

A functional requirement defines a function of a system or its component. A function is described as a set of inputs, the behavior, and outputs . Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish.

B. What is Non-functional requirements ?

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. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.

II. Requirements Elicitation :

A. What is the needs, goals and requirements for Elicitation ?

Goals :

1. Identify the real problem, opportunity or challenge
2. Identify the current measure(s) which show that the problem is real 3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it 4.

Get quality help now

Doctor Jennifer

Verified writer

Proficient in: Business

5 (893)

“ Thank you so much for accepting my assignment the night before it was due. I look forward to working with you moving forward ”

+84 relevant experts are online

Hire writer

Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly

5. Define the business "whats" that must be delivered to meet the goal measure(s) 6. Specify a product design how to satisfy the real business requirements Needs :

1. 'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

2. Problems of understanding.

The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.

3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility Requirements quality can be improved through these approaches:[3] 1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation. 2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.

3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects. 4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements. 5. Documenting dependencies. Documenting dependencies and interrelationships among requirements. 6. Analysis of changes. Performing root cause analysis of changes to requirements and make corrective actions.

B. What is requirements Elicitation ?

In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to asrequirements gathering.

C. What is the part of customer and stakeholder ?

The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.

D. What is Interviews and observation in requirement Elicitation ?

Every observation must be guided by clearly stated objectives. The analyst should know what data is to be collected, how observation will be done, when and where to observe, how the data will be collected and what the data will be used for after analysis.

Observation technique is best applied where:
A current process is to be monitored
The objective is to improve a process
Stakeholders find it hard to explain what they do or what their requirements are Processes are highly repeatable e.g. manufacturing
The validity of data collected through other means is in question