You are here: Home > Knowledge Base > Software Engineering Blog > Transactions in Use Cases, Non-functional Requirements, and Architectural Decisions
 
Newsletter
Newsletter
(Required)
Log in


Forgot your password?
 

Transactions in Use Cases, Non-functional Requirements, and Architectural Decisions

Architectural decisions are usually considered to be influenced mainly by non-functional requirements (NFRs). It is difficult to disagree with such thesis. However, some of the decisions are not directly driven by NFRs, but by the functionality of the system. It can also happen that some of the NFRs are not explicitly defined. In this entry, you can find a checklist containing 20 questions regarding functional requirements that can help you investigate required capabilities of a system architecture.

Architectural decisions are usually considered to be influenced mainly by non-functional requirements (NFRs). It is difficult to disagree with such thesis. Just imagine the architecture of an e-shop system which is going to handle couple of customers per day and the one for a shop like amazon.com. However, some of the decisions are not directly driven by NFRs but by the functionality of the system. It can also happen that some of the NFRs are not explicitly defined. This could result in serious problems during the implementation of the system.

The question arises if we can learn something about the NFRs and requirements towards architecture of the system by analyzing functional requirements? 

If you have functional requirements specified in a form of use cases you can get an overview of important architectural decisions by analyzing a few aspects of such requirements. You can analyze a structure of use cases as well as transactions that are constituting their scenarios.

Below you can find a checklist containing 20 questions which you should ask yourself when thinking about the architecture of your system. If you found them interesting you can find more information in the technical report.

Interoperability Issues

  • Q1: What type of interfaces actors use?
  • Q2: Does a single actor use many types of interfaces?
  • Q3: Are different interfaces used for exchanging the same business object?
  • Q4: Is the system actor active or passive one?
  • Q5: Is the communication with external actors synchronous or asynchronous?
  • Q6: Is communication interface capable of transporting business object between actors?

Object State Management Issues

  • Q7: How to handle object state changes?
    • Q7.1: How many CS transaction exist for the key business objects?
    • Q7.2: How complex is the change state diagram?
    • Q7.3: What actions accompany the change of states?
    • Q7.4: How many actors can change the state of a given business object?

Data Access Issues

  • Q8: What is the transaction profile of the system being developed?
  • Q9: How many data sources are present in the system?
  • Q10: How complex the business objects are, and how intensively they are used?

Dynamic Retrieve Issues

  • Q11: For which business objects dynamic retrieve should be available (none, all, or a subset of them)?
  • Q12: Should indexing mechanism be present in the system?
  • Q13: Should the filtering mechanism be provided?

Consistency Issues

  • Q14: How to deal with delete link and delete business object transactions?
  • Q15: What data-access transaction mechanism should be used?

Security Issues

  • Q16: Is the access control mechanism static or dynamic?
  • Q17: How secure communication interfaces between actors should be?
  • Q18: Do all actors will use the same access control mechanism?
  • Q19: Are permissions to business objects instance-specific or type-specific?
  • Q20: Are object transferred between system actors?
Document Actions
Supporting only the best, so that they can become even better