tarkvaran uded ja nende vormistamise tehnikad enn unapuu enn ounapuu@ttu ee n.
Skip this Video
Loading SlideShow in 5 Seconds..
Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu enn.ounapuu@ttu.ee PowerPoint Presentation
Download Presentation
Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu enn.ounapuu@ttu.ee

Loading in 2 Seconds...

play fullscreen
1 / 37

Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu enn.ounapuu@ttu.ee - PowerPoint PPT Presentation

  • Uploaded on

Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu enn.ounapuu@ttu.ee. Definition. Definition.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Tarkvaranõuded ja nende vormistamise tehnikad Enn Õunapuu enn.ounapuu@ttu.ee' - truda

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification.
  • Requirement engineering is a subdiscipline of systems engineering and software engineering
definition swebok
Definition SWEBOK

At its most basic, a software requirement is a propertywhich must be exhibited in order to solve some problemin the real world. Hence, a software requirement is aproperty which must be exhibited by software developedor adapted to solve a particular problem. The problem

may be to automate part of a task of someone who willuse the software, to support the business processes of theorganization.

requirements analysis
Requirements analysis

Conceptually, requirements analysis includes three types of activity:

  • Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.
  • Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
  • Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.
types of requirements
Types of Requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

Performance Requirements The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.

Design Requirements The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

Derived Requirements Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated Requirements A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.

defining a good requirement
Defining a good requirement

Correct (technically and legally possible).

Complete (express a whole idea or statement).

Clear (unambiguous and not confusing).

Consistent (not in conflict with other requirements).

Verifiable (it can be determined that the system meets the requirement).

Traceable (uniquely identified and tracked).

Feasible (can be accomplished within cost and schedule).

Modular (can be changed without excessive impact).

Design-independent (do not pose specific solutions on design)

n uete esitamise n ited
Nõuete esitamise näited

Prototüüpimine – MDD


archimate n ide
Archimate näide


Minu arvuti

t iendavad materjalid
Täiendavad materjalid





aine koduleht
Aine koduleht