A requirement that for a stakeholder can be perceived as being functional, can be considered as non-functional for a different one.

A candidate requirement is a requirement that was identified by some elicitation technique. The use of the term ‘candidate’ aims to emphasise the possibility of the requirement not being considered.

• It characterises partially the system behaviour as an answer to the stimulus that it is subject to.
• This type of requirements should not mention any technological issue.
• Ideally, functional requirements must be independent of design and implementation aspects.

• A non-functional requirement does not change the essence of the system functionalities (AKA the colour of the ball does not affect its functionality).
• Non-functional requirements are applicable to the system as a whole and not just to some of its parts.
• Generally, non-functional requirements cannot be modularised.
• The non-functional requirements are frequently emergent properties of the system at hand.

• An emergent property of a system is a property that can be associated with the system as a whole, but not individually to each of its components.
• Reliability is a good example of an emergent property. It is not sufficient that all components are reliable, for the respective system to be also reliable.
• The size of a software application is an example of a property that is not emergent.

• Non-functional requirements are crucial to decide the system architecture.

• Ease of use is related to the efficiency of utilising a system and with the mechanisms that reduce the errors made by the users.
• Personalisation is associated with the capacity of adapting the system to the tastes of the users.
• Ease of learning is concerned with the way users are trained to use the system.
• Accessibility indicates how easy it is to use the system, for people who are somehow physically or mentally disabled.
• System maintenance is divided into four types: preventive, corrective, perfective, and adaptive.
• Modifiability is related to maintenance and is dependent on how easy it is to locate the components that must be changed;

• Requirements Engineering is related to the transformation of informal descriptions of the real world into specifications in languages with a rigorous basis.
• Its objective is to increase the chances of the system under development to satisfy the future.
• Requirements engineering seeks to ensure the three following objectives:

1. all the relevant requirements are explicitly known and comprehended at the intended level of detail;
2. a reasonable and wide agreement about the requirements is obtained among the stakeholders;
3. all the requirements are duly documented, in conformity with the established formats and templates

• Based on some necessity or business expectation (usually due to the dissatisfaction in relation to the current situation)
• This recollection must be done in width and not in depth.
• At the end, the requirements engineer should be able to describe what is the client vision and return on investment (one must evaluate if what the client needs is already available in the market. If not, it must be created).

• Requirements elicitation techniques must:
  1. identify the sources of requirements;
  2. aid the various stakeholders to correctly describe the requirements.
• Inherently communicational: requires an in-depth interaction with the stakeholders
• Techniques:
  1. interview
  2. survey
  3. introspection
  4. ethnography
  5. focus group
  6. cooperative work
  7. domain analysis
  8. object-orientation
  9. prototyping
  10. scenario
  11. goal modelling
  12. persona

• usually to organise the requirements in cohesive groups
• The analyst must intervene, whenever the requirements:

• do not make sense;
• are in contradiction among them;
• are incoherent;
• are incomplete;
• are vague.

• involves communication and negotiation
• Results can have a significative impact on the acceptance of the final system.
• Another form of handling conflicts consists in adopting prioritisation techniques, to sustain the choice of the requirements subset to be implemented at each instant.

• Requirements documents serve as the principal reference to the subsequent phases
• The requirements document is organised according to two distinct perspectives:

1. user requirements, that describe the expectations and the necessities of the users;
2. system requirements, that establish the agreement between the client and the development team.

• The structure/formality of the documentation should vary in line with the system characteristics and the adopted process

• The objective is to ensure that the requirements define the system desired by the client.
• One should examine the requirements document through inspections or technical reviews of the specifications, to evaluate if it describes the intended system.
• Validation is a testing activity.

• The requirements set is constantly changing.
• Mechanisms to manage that instability context are needed, in order to evaluate the impact that the changes can have on the project.
• The requirements management activity seeks to aid the development team to identify, control and trace the requirements and their changes.

The definition of a generic template for the documents that specify the requirements is an important aspect, since there is a great diversity of engineering systems and projects. Without ir, the degrees of freedom are excessive, making the documents quite different from case to case.

• Writing requirements in a natural language is inescapable.
• Engineers must be able to write requirements in a natural language and, in general, must know how to communicate with any common person (no jargon).
• Writing in an effective way is a task prone to errors.
• Writing requirements, according to a set of principles and recommendations, is important, making it a process with continuous enhancement, through training and practice

• Each requirement must be represented by one sentence and each sentence should just represent one requirement. The objective is to have the requirements written clearly and this presupposes short and simple sentences.
• The sentences must be affirmative and written in the active voice. Avoid negative and passive voice.
• References to other documents should be limited, especially those with restricted and limited access.

• Avoid the use of terms that may create confusion, especially synonyms of words that represent important concepts.
• Acronyms and abbreviations must be used with great care.
• Avoid using synonyms just to make the text less repetitive.
• Ambiguity means that there are two or more possible interpretations for a sentence
• Situations of ambiguity must be corrected, with the objective of making a sentence clearer
• Ambiguous sentences can be complemented with other materials (tables, figures, schemes), to make the meaning clearer.
• Ambiguity is manifested also when two or more conflicting requirements are defined.
• The resolution for ambiguity can be solved through negotiation techniques.
• Examples of vague terminology: easy to use/learn, versatile, flexible, intuitive, modern, improved, efficient, approximately, more possible, minimal impact...
• Vagueness can be mitigated by complementing the writing of the requirement with the definition of verifiable criteria (AKA use units of measurement)
• To solve delusion, one should avoid any sort of wishful thinking, in which one is trying to reach the impossible.
• Have a realistic attitude. Avoid these therms: 100% reliable, totally safe, never fails, satisfies all users, handle all unforeseen situations...
• Requirements that contain coordinating conjunctions are especially susceptible to create ambiguity situations (in reality we have 2 requirements and not 1).
• Avoid using of coordinators like: for, and, nor, but, or, yet, so,...
• To solve multiplicity divide one requirement into simpler ones.
• Avoid indicating how the system will be able to satisfy a given requirement. There is such a thing as detailing too much a requirement and making design decisions too prematurely;
• Focus of the writing process on functionalities;
• References to component names, materials, database fields, or technological aspects should be avoided;
• Project plans and the way the project is scheduled are important aspects to consider, thus they should not be included in the requirements document;
• Avoid the inclusion of dates, phases and project activities in the requirements. That type of information must be available in a different document - project plan.

1. Homonymy: occurs when two or more distinct and unrelated meanings accidentally share the same lexical form.
2. Polysemy: occurs when the same lexical unit supports two or more distinct meanings, but somehow semantically related.
3. Use of possessive pronouns: imprecise uses of possessive pronouns in the third person (in the singular or plural) can create ambiguity. Example: The director call the doctor about his problems.
4. Conjuntions (1): A problem of interpretation exists when, after an enumeration, one writes something that can be applied to all the elements enumerated or just to the last one. Example: The managers inform the directors and the secretaries, because they are responsible for editing the document.
5. Conjunctions (2): Also, the difference between the linguistic OR and the logical OR (as well as the AND) are also an issue. Conjuctions should be eliminated whenever possible.

• Requirements elicitation permits to understand what are the requirements of a given system. It allows comprehending the necessities and expectations that stakeholders have with respect to a given system. The activities have a communicational nature, which involves techniques related with the social sciences and organisational theory.
• Alternative designations: requirements discovery, capture, recollection, acquisition, extraction or crawling

• The activities related to requirements should not be exclusive of the initial phases of the lifecycle.
• The development team must adopt an approach that addresses and favours handling the requirements in all the lifecycle.

1. Contact persons that know well the problem to identify all the restrictions that could limit the respective solution ( uncertainty and an increase of information and knowledge)
2. Prepare the requirements document that describe the behaviour and the characteristics that are expected for the system (organisation of the ideas, the resolution of conflicting views, and the elimination of inconsistencies and ambiguities)

It is recommended to collect informations to understand if there is any particularity to be recorded for some of the following groups of persons, while they interact with the system:

1. disabled and handicapped persons;
2. people with low literacy levels;
3. those that do not dominate the languages used by the system;
4. people with visual difficulties (users of glasses, colour-blind, or blind people);
5. persons transporting or handling substances and objects;
6. persons with reduced dexterity to interact with computer-based systems.

• The client should be provided with complete technical documentation, to permit the installation and maintenance of the system throughout its lifecycle.
• The client has the power to decide about several issues, namely the scope, functionalities, and cost.
• The clients are not always the users of the system.

• For a mass-market product, the customers are the persons that will acquire that product when available.
• The act of buying does not need to be associated with a financial transaction between the customer and the seller.

• The identification of the negative stakeholders allows to identify any attempt to sabotage the system development.
• Their presence in the requirements elicitation activities is relevant, to identify and comprehend the personal and political relations within an organisation

• Great freedom to the conductor of the interview
• Often ends with low-quality results
• Should be carried out in a structured way to get better results
• Process: identify interviewees; prepare interview; conduct interview; conclude interview
• Interviewees should include some stakeholders (the client + some users of the system, bare minimum)
• interviewees must (globally) be a representative sample of the community
• possible to add persons to be interviewed during the process of interviewing ("who shall I also interview?")
• interviewer should put the interview in its context, explaining the aims, duration, issues to be addressed and how the collected information will be processed
• Whenever available, the use case diagrams can be used as a reference; models or figures can be used to encourage the interviewee to propose modifications.
• The terminology of the problem should be used (NO JARGON!)

• Common use to elicit requirements, especially initially
• Uses a questionnaire to handle information gathered from multiple persons
• Process: identify audience + objectives; conceive questionnaire; determine sample; recruit participants; conduct survey
• Questionnaire: set of questions to be answered
• When the same questionnaire is used for all persons, it becomes possible to handle statistically the collected answers.
• Success is highly dependent on the way the questionnaire is conceived.
• If questions are not focused, are poorly formulated or appear in the wrong order, the answers may be misleading
• One should avoid the use of negative questions
• Unanswered questions can be tackled through the use of computer-based tools (virtual forms) -> not always desirable, forces the respondent to have access to a computer
• The survey must be used as a preliminary technique that aids in the preparation of the interviews

• most basic, obvious, and rudimentary of all requirements elicitation techniques
• The analyst defines the requirements for a given system based on what she thinks are the necessities of the stakeholders, by putting temselves in the role of the client or the users.
• They must reason based on premises of the type “if I were the client, I would like the product to . . .”.
• Extensively used, namely when the requirements engineers have a deep knowledge about the problem domain
• Can be used only as a starting point for the adoption of other requirements elicitation techniques

• Sometimes, the client just defines some generic objectives for the system, not indicating with detail its functioning.
• A prototype-based approach can be the most adequate choice to support the requirements elicitation process.
• This approach assumes an iterative process
• Process: elicit requirements; construct prototype; tets prototype
• The prototype serves simply as a mechanism for capturing the requirements.
• As soon as one considers that the requirements of the client are clearly understood, the prototype is abandoned.

• common in the advertising area and recently has gained popularity for requirements engineering
• A persona is a fictitious person that represents an important type of the users of the product under development.
• A persona is an archetype of the persons that are part of the target audience.
• A persona should be conceived to represent those persons, in what is essential and distinctive.
• The personas are a technique of market segmentation
• Process: identify problem; create personnas; introduce personnas; use personnas; evaluate personnas

• Modelling permits the cost-effective use of the model in place of the real-world object or process for some purpose.
• Modelling is related to abstraction, simplification, and formalisation.
• A model represents the reality for a given purpose.
• A model must not represent all aspects of reality.

• An iconic model is perceived as imitating the system, being similar with respect to some of its properties.
• A physical model is typically a smaller representation of the original object.
• It can be larger if the original object is too small for humans.
• Usually, a physical model is not as accurate or complete as reality.
• Example: maquetes of buildings

• In electrical engineering, models are a set of equations that represent the electrical circuits by applying some laws.
• Example: Ohm’s law -> V = R × I .
• Typically, a symbolic model does not resemble the system it represents, but is fundamentally arbitrary or conventional.
• Arbitrariness is the absence of any necessary connection between a linguistic form and its meaning.
• A class is represented in UML by a rectangle, but this is a pure convention. The word ‘strawberry’ has no relation to the fruit itself; it is a pure convention.
• Topological maps are also an example of a symbolic model. Those subway maps as well.

• With a descriptive model, one can reason about the properties or the behaviour of the system.
• An example is a model of the weather that allows meteorologists to forecast it.
• In almost all natural sciences, models are descriptive as scientists try to understand how the natural world behaves.
• In engineering, descriptive models are used in reverse engineering when one wants to reason about an existing system without directly affecting it.
• AKA models which are written down descriptions of what we are trying to represent (that exists/is something tangible)

• Prescriptive models are adopted in the so-called forward engineering.
• In software engineering, models created during the analysis stage describe the problem at hand.
• When prescriptive models are used, the target system does not exist yet! It must be engineered.
• Most of the models used in engineering are prescriptive

These models are used for describing the components or modules that are part of the system, so they serve for conceptualising the system architecture.
UML class, component, and deployment diagrams are used for representing structural models.

-This type of models address the behaviour of the system, being thus especially relevant in the analysis phase.
Examples: finite state machines, Petri nets, and data flow diagrams (DFDs).

• Modelling, done during the analysis phase, aims to specify the requirements of the systems.
• Most software models are, in industrial contexts, represented in UML.
• This language presents many types of diagrams.
• Most developers use in practice only a subset of those diagrams and from those also resort just to part of their available constructors.
• This situation is easily framed in the Pareto law (or 80/20 rule- for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few")).

• The domain model expresses enduring truths about the universe that is relevant to the system at hand.
• That description must include:
  1. a definition of the 1 of that domain, providing examples of systems or generic rules of inclusion,
  2. the vocabulary of the domain (i.e., the glossary with the principal terms)
  3. a model of concepts that identifies and relates the concepts of that domain.

• The utilisation of use case models serves essentially two purposes:
  1. defining the frontier of the system with the environment,
  2. specifying the functionalities that the system makes available to its users.
• A use case diagram resorts to, as basic elements, use cases and actors.
• The usage of verbs is recommended to characterise the use cases, thus enhancing their functional nature.
• Use cases do not model processes/workflows
• You can use abstractions for actors
• Many small use cases with the same objective may be grouped to form one (more abstract) use case
• The various steps of a use case are not separate use cases themselves! NO functional decomposition

• Class models are necessary to indicate the existing classes and their relations.
• These models are contemplated by all object-oriented software development methods.

• In same cases, it is necessary to model the dynamic aspects related to the exchange of messages between objects.
• Those models can be represented by interaction diagrams.
• An interaction model can be used for representing an instance of a use case.
• They describe how a group of objects communicate amongst them.
• In UML (version 2.2), there are four different types of diagrams that allow interaction models to be represented.
• We present only sequence diagrams.

• Class models do not allow the dynamic behaviour of the instances of the classes to be determined.
• The use of state diagrams has become popularised in the hardware domain, but its modelling capacity has proved to be useful in diverse computing areas.
• State diagrams can be used for defining the (dynamic, temporal) behaviour of a class.
• In a conventional state diagram, one and only one state is active in each instant.
• A state is an ontological condition that persists for a significant period of time that is distinguishable and disjoint from other similar conditions.

• Activity models are useful to relate the control flow among the activities of a given business process.
• These models address behavioural aspects of the systems or entities under consideration.
• These models are appropriate when the behaviour change occurs, mainly due to the end of the action/activity executed

• A software architecture is the result of technical, business and social influences.
• Software architecture is about the design of the system and the impact it has on its qualities.
• The architecture acts as the skeleton of the system, constrains it, and affects its quality attributes.
• Applying software architecture ideas requires a conscious shift to embrace its abstractions.
• If you do not consciously choose the architecture of your systems, then it end up being a big ball of mud (“spaghetti code”) - AKA a software system that lacks a perceivable architecture.
• Every system has an architecture, whether or not it is documented and understood.

• Each project faces risks, so there is no single correct way to do software architecture
• Often there is no architecture work, since there is no risk when a proven architecture is reused.
• The harder the problem is, the more one needs to pay attention to the architecture choices.
• A software’s design consists of the decisions and intentions that are in the heads of the developers.

• Developers must pay attention to functionality, but a system has also quality attributes.
• A system’s architecture enables or inhibits qualities such as security or performance.
• Functional requirements that change are a challenge, but evolving quality attributes can force drastic changes.
• Example: a system to support 100 users may be impossible to scale up to 100,000 without a drastic architectural change.
• Architecture is likely to require more attention in systems with large scale or high complexity.
• When the system is simple, its architecture is unlikely to sink the project, so one pays little attention to it.
• There is no such thing as an inherently good or bad architecture.
• An architecture is more or less fit for some purpose.
• Architectures can be evaluated but only in the context of specific stated goals.

• Architecture and functionality can be balanced.
• Architecture is mostly orthogonal to the system’s functionality.
• There is no single best architecture, but architectures are more suited to some tasks than others.
• A system’s architecture can be changed, but yet keeping its functionality
• The same architecture can be used on a system with different functionality.
• A poor architecture choice can make functionality and quality attributes difficult to achieve.

• The architecture should be the product of a small group of architects with an identified leader (avoid “design by committee” anti-pattern).
• The architect should base the architecture on a prioritized list of quality attributes.
• The architecture should be documented using views.
• The views should address the concerns of the most important stakeholders.
• The architecture should be evaluated for its ability to deliver the system’s important quality attributes.
• The architecture should lend itself to incremental implementation.

• Developers in that domain may have to justify a choice that differs from the presumptive architecture.
• Presumptive architectures are similar to reference architectures.
• A reference architecture is a family of architectures that describes an architectural solution to a problem.
• Presumptive architectures succeed because they are a good match for the common risks in the domain.
• IT developers who use the presumptive N-tier architecture will almost always do fine.

• The architecture model will be detailed in some areas and sketchy, or even non-existent, in others.
• Models are an intermediate product.
• One can stop working on the models once he is convinced that the architecture is suitable for addressing the risks.
• The risk-driven approach facilitates the decisions, but it cannot make judgments.
• It identifies prioritized risks and corresponding techniques and guides on asking the right questions about the design work.

• Architects need techniques to achieve particular qualities.
• The quality requirements specify the responses of the software system to realize business goals.
• Tactics are used by the architect to create a design.
• Tactics connect quality attribute requirements with architectural decisions.

1. availability tactics
2. modifiability tactics
3. performance tactics
4. security tactics
5. testability tactics
6. usability tactics

• A failure occurs when the system no longer delivers a service that is consistent with its specification.
• This failure is observable by the users.
• A (combination of) fault(s) has the potential to cause a failure.
• Recovery or repair is an important aspect of availability.
• Availability tactics aim to avoid faults from becoming failures or at least reduce the effects of the fault and make repair possible

• Google loses 20% traffic if their web sites respond 500 ms slower than usual.
• Amazon loses 1% of revenue for every 100 ms in latency.
• A Mozilla study shows that if the webpage is not loaded within 1 to 5 seconds, users will leave it.

1. a reusable solution to a recurring problem
2. a pre-designed chunk, tailored to fit a given situation
3. a package of design decisions that can be reused as a set

• system patterns (architectural styles)
• design patterns
• code patterns

• Constraints can act as guide rails that point a system where you want it to go.
• One can think of a style as a prefabricated set of constraints that can be reused.
• The consistency brought about by the constraints of the style can encourage clean evolution of the system, which can make maintenance easier.
• Communication among developers is improved since the simple name of a style conveys design intent.

• The essential element of the layered style is a layer.
• The essential relationship is a uses relationship, a specialization of a dependency relationship.
• The layered style consists of a stack of layers.
• Each layer acts as a virtual machine for the layers above it and their ordering forms a DAG.
• In a simple layered style, a layer can use only the layer directly beneath it.
• Quality attributes promoted: modifiability, portability, and reusability.
• The layered style can vary greatly from its platonic form to its embodied form.
• In practice a layered style may violate its constraint
• You may see skipping of layers or lower layers using upper layers.
• Lower layers can safely communicate with higher layers if they use a callback mechanism.
• “Lasagna code” refers to a program structure that follows the layered style.

• It has no evident structure.
• Promiscuous sharing of information is typical, to the extent that data structures become effectively global.
• Repairs and maintenance are expedient and resemble crude patches rather than elegant refactorings.
• No effort is made to enforce any conceptual integrity or consistency (“spaghetti code”).
• Such systems have poor maintainability and extensibility.
• This style is a good enough strategy of engineering.

• Data flows through pipes to filters that work on the data.
• The pipe-and-filter network is continually and incrementally processing data.
• The pipe-and-filter style consist of four elements: pipes, filters, read ports, and write ports.
• A filter reads input from the input ports, does some processing, and writes output to the output ports.
• It repeats this until it is time to stop.
• Filters can enrich, refine or transform the data
• Each filter applies a function to its input.
• Pipes must only transport the data in one direction, without changes, and in order.
• Loops in the network are rare and often prohibited.
• Filters may not interact with each other, even indirectly, except through pipes.
• Filters cannot share state with each other.
• A filter incrementally reads the input and, as it processes that input, incrementally write its output

• Data flows from stage to stage.
• Each stage completes all of its processing before it writes its output.
• Data can flow between stages in a stream but is more often written to a file on disk.
• It has similar constraints to the pipe-and-filter style.
• Each stage is similarly independent.
• A stage depends on the data that it takes in.
• Stages do not interact with each other except through the input and output streams or files.
• Both Batch-sequential style as well as Pipe and filter style decompose the task into a fixed sequence of computations, interacting only through data.

• Independent components interact with a central model (data store) instead of with each other.
• Every model-centered system has a model component and several view, controller, or view-controller components.
• This style is related to several design patterns, including the document-view, MVC, and observer.
• Views and controllers depend only on the model, not on each other.
• Modifiability is enhanced because the producer and consumer of information are decoupled.
• The system is extensible since unanticipated views and controllers are easily added.
• It can be easier to manage and persist state, since it is centralized in the model component.
• Concurrency may be promoted since views and controllers can run in their own threads or processes.
• This style is useful when one does not know the future configuration of the system.

• Independent components publish events and subscribe to them.
• A publishing component is ignorant of the main reason why an event is published.
• A subscribing component does not know why or who published the event.
• This style defines publish and subscribe ports, and one connector (an event bus connector).
• Any kind of component can publish (subscribe) events as long as it uses a publish (subscribe) port.
• One component can publish an event and many components can subscribe to it.
• The event bus connector delivers events:
  • publishers trust that events are delivered to subscribers
  • subscribers trust that they receive events they subscribe to
• Producers and consumers of events are decoupled.
• The system is more maintainable and evolvable.

• Clients synchronously request services from servers.
• The client can request that the server do the work.
• Communication is initiated by clients, not the server
• The server does not know the identity of the client until it is contacted.
• Clients must either know the identity of the server or know how to look up the server.
• The client-server style has several variation points:
  • connectors may be synchronous or asynchronous
  • there may be limits on the number of clients or servers
  • connections may be stateless or stateful (i.e., sessions)
  • the system topology can be static or dynamic
• Another variant is the N-tier style
• It uses two or more instances of the client-server style to form a series of tiers
• Requests must flow in a single direction
• A common case is a 3-tier system where:
  • a user interface tier acts as a client for the business logic tier server
  • business logic tier server acts as a client for the persistence tier server
• Tiers have exclusive functional responsibilities.
• The user interface tier is exclusively responsible for user interaction
• The persistence tier exclusively saves persistent data

• Nodes communicate with each other as peers.
• Hierarchical relationships are prohibited.
• Each node has the ability, but not obligation, to act both as a client and as a server.
• The result is a network of nodes operating as peers.
• A node can request or provide services to any node.
• The elements of the peer-to-peer style are similar to those of the client-server style.
• A peer-to-peer connector has identical roles on either end allowing both requests and responses.
• A peer-to-peer system is egalitarian where the client-server style is hierarchical.

• This style is appropriate for processing large datasets (search engines and social networking sites)
• Simple programs (sorting or search) execute slowly on large datasets, if a single computer is used.
• This style enables the computation to be spread across multiple computers.
• As the number of computers used increases, the likelihood that one of them will fail also increases.
• This style enables recovery from such failures

• The previous architectural styles have been from the module and runtime viewtypes
• The styles from the allocation viewtype are more likely to be discussed by network engineers than software architects