Detecting plagiarism made easy.
Score: 0.7573843002319336; Reported for: String similarity
Open both answers
Present in both answers;
Present only in the new answer;
Present only in the old answer;
1. Functional requirements specifies a function that a system or system component must be able to perform. It can be documented in various ways. The most common ones are written descriptions in documents, and use cases.
2. Use cases can be textual enumeration lists as well as diagrams, describing user actions. Each use case illustrates behavioural scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that must be implemented to allow a user to perform each use case.
3. Functional requirements is what a system is **supposed to accomplish**. It may be
- Technical details
- Data manipulation
- Data processing
- Other specific functionality
4. A typical functional requirement will contain a unique name and number, a brief summary, and a rationale. This information is used to help the reader understand why the requirement is needed, and to track the requirement through the development of the system.
[LBushkin](https://stackoverflow.com/a/16476014/1045444) have already explained more about Non-functional requirements. I will add more.
1. Non-functional requirements are any other requirement than functional requirements. This are the requirements that specifies criteria that can be used to **judge the operation of a system, rather than specific behaviours**.
2. Non-functional requirements are in the form of **"system shall be <requirement>"**, an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.
3. Non-functional requirements - can be divided into two main categories:
- **Execution qualities**, such as security and usability, which are observable at run time.
- **Evolution qualities**, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
4. Non-functional requirements place restrictions on the
product being developed, the development process,
and specify external constraints that the product must
5. The [IEEE-Std 830 - 1993](http://www.utdallas.edu/~chung/RE/IEEE830-1993.pdf) lists 13 non-functional requirements to be included in a Software Requirements Document.
> 1. Performance requirements
> 2. Interface requirements
> 3. Operational requirements
> 4. Resource requirements
> 5. Verification requirements
> 6. Acceptance requirements
> 7. Documentation requirements
> 8. Security requirements
> 9. Portability requirements
> 10. Quality requirements
> 11. Reliability requirements
> 12. Maintainability requirements
> 13. Safety requirements
Whether or not a requirement is expressed as a functional or a non-functional requirement may depend:
- on the level of detail to be included in the requirements document
- the degree of trust which exists between a system customer and a
Ex. A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date [update] this number needs to be, is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the [displayed] record count within an acceptably short interval of the number of records changing.
1. [Functional requirement](https://en.wikipedia.org/wiki/Functional_requirement)
2. [Non-functional requirement](https://en.wikipedia.org/wiki/Non-functional_requirement)
3. [Quantification and Traceability of
I believe the first two questions are the result of a wrong understanding of Process Managers (aka Sagas, see note on terminology at bottom).
Shift your thinking
It seems like you are trying to model it (as I once did) as an inverse aggregate. The problem with that: the "social contract" of an aggregate is that its inputs (commands) can change over time (because systems must be able to change over time), but its outputs (events) cannot. Once written, events are a matter of history and the system must always be able to handle them. With that condition in place, an aggregate can be reliably loaded from an immutable event stream.
If you try to just reverse the inputs and outputs as a process manager implementation, it's output cannot be a matter of record because commands can be deprecated and removed from the system over time. When you try to load a stream with a removed command, it will crash. Therefore a process manager modeled as an inverse aggregate could not be reliably reloaded from an immutable message stream. (Well I'm sure you could devise a way... but is it wise?)
So let's think about implementing a Process Manager by looking at what it replaces. Take for example an employee who manages a process like order fulfillment. The first thing you do for this user is setup a view in the UI for them to look at. The second thing you do is to make buttons in the UI for the user to perform actions in response to what they see on the view. Ex. "This row has `PaymentFailed`, so I click `CancelOrder`. This row has `PaymentSucceeded` and `OrderItemOutOfStock`, so I click `ChangeToBackOrder`. This order is `Pending` and 1 day old, so I click `FlagOrderForReview`"... and so forth. Once the decision process is well-defined and starts requiring too much of the user's time, you are tasked to automate this process. To automate it, everything else can stay the same (the view, even some of the UI so you can check on it), but the user has changed to be a piece of code.
***"Go away or I will replace you with a very small shell script."***
The process manager code now periodically reads the view and may issue commands if certain data conditions are present. Essentially, the simplest version of a Process Manager is some code that runs on a timer (e.g. every hour) and depends on particular view(s). That's the place where I would start... with stuff you already have (views/view updaters) and minimal additions (code that runs periodically). Even if you decide later that you need different capability for certain use cases, "Future You" will have a better idea of the specific shortcomings that need addressing.
And this is a great place to remind you of [Gall's law] and probably also YAGNI.
> 3. Any other reference material on the net for implementation of event sourced Sagas? Anything I can sanity check my ideas against?
Good material is hard to find as these concepts have very malleable implementations, and there are diverse examples, many of which are over-engineered for general purposes. However, here are some references that I have used in the answer.
[DDD - Evolving Business Processes]
[DDD/CQRS Google Group] (lots of reading material)
**Note** that the term Saga has a different implication than a Process Manager. A common saga implementation is basically a routing slip with each step and its corresponding failure compensation included on the slip. This depends on each receiver of the routing slip performing what is specified on the routing slip and successfully passing it on to the next hop or performing the failure compensation and routing backward. This may be a bit too optimistic when dealing with multiple systems managed by different groups, so process managers are often used instead. [See this SO question] for more information.