Requirement Analysis

Pressman [1] informs us that the execution of seven distinct functions performs the requirements engineering process: conception, survey, elaboration, negotiation, specification, validation, and management. The requirements modeling action results in one or more of the following types of models:

  • Requirements scenarios are represented from the point of view of various “actors” in the system.
  • Data models that represent the information domain for the problem.
  • Class-oriented: representing object-oriented classes (attributes and operations) and how classes collaborate to meet system requirements.
  • Flow-oriented models represent the functional elements of the system and how they transform data as it travels through the system.
  • Behavioral models that represent how software behaves as a result of external “events.”

Software requirements can be classified as follows [2]:

  • Functional Requirements: these are statements of services that the system must provide, how the system must react to specific inputs, and how the system must behave in certain situations. In some cases, functional requirements may also spell out what the system should not do.
  • Non-Functional Requirements: are restrictions on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Unlike the individual features or services of the system, non-functional requirements often apply to the entire system.

Non-functional requirements can come from the characteristics required for the software (product requirements), from the organization that develops the software (organizational requirements), or from external sources [2].

 

QFD (Quality Function Deployment) is a quality management technique that translates customer needs into technical software requirements. QFD “focuses on maximizing customer satisfaction through the software engineering process” [1]. QFD identifies three types of requirements: Normal Requirements, Expected Requirements, Fascinating Requirements.

References:

[1] Pressman, Roger. Software Engineering 6ª edition (2006).
[2] Sommerville, Ian. Software Engineering 9ª edition (2012).

Discipline in Study

Many students try to study the entire content of the tests after launching the notice. This strategy is doomed to failure due to lack of time. Studies must start before the public announcement To explore the full range. This statement may seem illogical, as we may end up studying for a long time until the actual test, or worse, we may launch the test with subjects different from the ones we are looking for. That’s the price to pay.

The top quality of the contestant is the discipline of always studying. This regularity creates the approved and not fancy methods that “unveil the secret of the contests.” There are no secrets and no easy paths. The best analogy I’ve seen for this was Professor Granjeiro comparing studying competitions with a marathon. Only those in constant training can run a marathon. Even elite athletes who are without training cannot recover in a short period.

For those looking for magic formulas, I inform you that the process is simple: separate the material, study every day, stay focused, take exams for competitions. By following these steps, approval is guaranteed. So why do many give up? The point is, studying always is hard. So, are you willing to pay the price?