Architecture: Functional Requirements

What are Functional Requirements?

Functional requirements detail the behavior of the intended system. This is from the workflow to the end-user interface. You want to ensure that each functional requirement that you capture is just that. One. You don’t want to have more than one functionality written in a requirement for various reasons:

1. You’ll lose money. When you go to design the system, then you might realize that the bunched-up requirements are really unrelated, and you will have to come out of your pocket to still give your client what they paid for.
2. You will screw up your design. As I said in the first reason, you might realize that the design functions are different. When you try to cut corners, then you will end up with a design that is more flawed than it should be.
3. You will end up losing tons of resources and time to fixing the system. It is like a domino effect. If you don’t have solid requirements, then your system design will fail. If your system design is flawed, then the building of the system will be.

Yes, you should group your requirements, so that you have them organized in a way that it’s easy for everyone involved to follow.

How to Group Requirements?

There are several ways to group requirements, but you want to do it in a way that doesn’t confuse anyone.  Remember that requirements are something that are usually viewed by multiple group of people with varying levels of knowledge. Therefore, you want to ensure that you don’t alienate any of them. Here are two ways to group requirements:

• By Functionality – This is probably the best way to group your requirements.  You want to group similar requirements that are part of the same functional area.
• By Process – This is similar to functionality, except you can have different functions in one process.  If this is the route you want to take, ensure that the process is a small one.

There are other ways, like input and output, so it’s up to you.  Just remember: Think about all the user groups involved.

What Functional Requirements Should I Capture?

Here are the basic functional requirements that you should capture.  You have to remember that not all systems are the same, so you might have additional ones you have to capture for your system.

Business Rules

Every company works differently, so you want to capture all of their business rules. Business rules will influence how the system works, its security, and data management.

Interface Functional Requirements

Maybe once upon a time, you could have a system that was standalone, and everyone was happy.  In reality, times have changed.  Systems talk to one another, processes overlap, and workflows as well. Therefore, you have to capture the all the different kinds of interfaces because each of them will affect your system. These are usually hardware, software, and user. You want to ensure that you capture the following information for each interface requirement group:

• Description of the interface
• Each data element, and how it transfers to and from the system
• Interface workflow

Remember that pictures are always a great thing to have, so try to have pictorial views of the information you are trying to explain.

Data Functional Requirements

If you don’t understand the data, then how will you understand what the system needs to do? You have to detail each data element, its format, any dependencies to other data elements, groupings (if any), and how it is used in the system. Also, you want to describe how it is captured. There are times that you will be doing some changes to the data flow.  You should capture the “as is” and how it will be transformed to the “to be.”

A good resource to create a data dictionary that can capture all this information.  If you ever need to see the detail of a data element, you have it right there.  It makes it easier than having to sift through a long, detailed document.

Operational Requirements

This is the bulk of your functional requirements.  These requirements detail how the system will run and communicate.

Security

Security requirements are the different levels of security that the system will have.  This is from user security to administrative security, all the way to data security.  You want to capture if user groups will have different levels of access.  This means if one user group will be able to view sensitive information while another won’t. You also want to discuss the security of the location(s) that the system will be held in.

Audit Trail

Audit trails are important.  For instance, if you have a security breach or a failure, you can always go back to the audit trails to find out what happened.  There are different kind of audit trails.  There are some for data and interfaces.  This kind of audit trail will capture if the interface ran, what kind of data was captured, was it successful or not, and time.

The other kind of audit trail is user information.  Things like what user accessed the system, when, what kind of and what kind of information was accessed.

There are other kinds of audit trails. Remember, audit trails are your friends, so don’t skip this step.

Data Currency

Data Currency is self-explanatory.  It keeps track of how recent the data is. You also want to have the most recent data in your system.  If you don’t, then this can cause problems for users trying to access this data for their job.

Reporting Requirements

Systems usually output reports of all kinds.  Therefore, you really want to think and analyze all the reports that the client is going to need in the system.

Data Retention

You want to think about the different data that is collected, and the length that it has to be retained in the system.  Data retention also is where you want to discuss archiving.  You can archive data for longer periods of time, but how much data has to be right in users’ grasp.

Architecture: 15 Areas to Think About When Writing Non-Functional Requirements

Non-functional requirements should be defined when you are also creating and writing functional requirements. These are requirements that detail the constraints and quality standards that the system you are building should adhere to. You can find out what these non-functional requirements should be by your experience, interviews, and industry standards. Also, you can use functional use cases to try and discover what non-functional requirements should be.

Here are some areas that you should have in your non-functional requirements document:

1. Reliability - Reliability is the chance that the system processes work correctly without being aborted. Some of the potential resulting losses that you should consider are:
• Complete or partial loss of the ability to perform a mission-critical function
• Loss or corruption of data Loss of user productivity
• Time between failures
2. Recoverability - Recoverability is the ability to restore function and data in the event of a disaster, either natural or man-made. Recoverability ensures that if any kind of system failure occurs, regardless of the reason, the system will operate with minimal interruption. You should think about:
   • Where backup copies of the system and data held within it will be stored
   • Discuss plans to have a Continuity of Operations Plan (COOP) and procedures for the system
   • How soon after a failure is detected must function be restored
   • How soon after corruption is detected must function be restored
3. Data Backup/Restore – Data Backup/Restore is a measure of how frequently data is backed up and the speed of data restore from backup. You should think about:
   • If the hardware, data, and onsite backup are destroyed, how soon must the application be restored
   • Do you have another site that has a full backup of the data?
   • How many backups do you have?
   • If one server goes down, how many backup servers do you have?
4. Availability – System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed. Definitely think about time zones, schedules, and user location.
5. System Maintenance – There should always be regular system maintenance. You should think about how much time you need to do maintenance, and how and when you will notify users.
6. Performance – Performance details the way the system will perform for users. Think about:
   • What is the response time for reports, queries, and updates?
   • What is the total number of user sessions open for the entire application?
   • What is the total number of concurrent sessions that can be opened by a single user?
   • What is the total amount of idle time before the user session is forced to terminate?
7. Usability – Usability is the system support of the execution of user tasks (i.e., presentation of information and management of user interaction). Think about:
   • How easy it is for user to learn the system
   • How easy it is for user to memorize steps
   • How efficient is the system
8. Visibility – Visibility discusses how the system looks to user. Is it easy for them to see the font, screens, reports, etc.
9. Data Retention - Data Retention details the length of time that various data will be retained in the system.
10. Fault Tolerance – Fault Tolerance is a measure of how well the system can maintain normal operations when defects are encountered. Think about:
    • How every threat will be identified
    • How will you warn the user
    • Will you disable the feature
    • Will you remove the feature
11. Maintainability – Maintainability is a measure of how easy it is to correct defects in the software.
12. Interoperability – Interoperability is a measure of how easy it is to integrate the software with other systems.
13. Error Handling – Error Handling will be in place to respond to reports of security flaws in the system. Reported vulnerabilities must be tracked throughout the process to ensure they are triaged, corrected, and tested. When a security flaw is discovered in an application deployed in a production environment, notification to users must take place as quickly as possible.
14. Threat Modeling – Threat Modeling is the process of identifying potential threats to the application, risk ranking these threats, and selecting appropriate countermeasures or mitigations for the threats. Threat modeling is a critical step in securing an application from attack. The threat model will be reviewed for each application release and updated as required to reflect the changes in application design and functionality. As potential threats are discovered and the implementation details of the application become known, the threat model will be updated.
15. Reusability – You should think about having a system that parts of it can be easily reused in other systems. This will save the company them and money in future projects.

Architecture: Can You Relate?

Your success as a software architect depends on your relationships with stakeholders.

Being a software architect is all about relationships. No, forgetting your anniversary or not getting along with your mother-in-law won’t necessarily have any impact on your success as a software architect. But unless an architect’s relationships with project stakeholders are based on clear communication and a thorough understanding of expectations, the project is likely to end in a scene befitting a reality television show, with at least the possibility of flying furniture and crushed dreams.

So if you want to succeed as a software architect, establishing a solid relationship with stakeholders and a crystal-clear understanding of their expectations must be job #1 on any project.

The first step in that process is knowing whom you’re dealing with. Identifying stakeholders is essential. “You need to know who has the power to call an engagement a success or failure,” says Pat Shepherd, enterprise architect at Oracle.

But there’s more to building relationships than memorizing names and roles—you need to get inside stakeholders’ heads. “Make sure you know the stakeholders and what’s driving them,” says Oracle ACE Director Ronald van Luttikhuizen, a solution architect and senior consultant at Approach Alliance, a Netherlands-based information and communications technology consultancy focusing on SOA and business intelligence.

Randy Stafford, a software architect with the Oracle Coherence development group, agrees. “The first thing I do is make sure I understand the motivation for the project, because it usually translates directly to measurable success criteria,” Stafford says.

Once you know what your stakeholders want, you need to make sure they understand what you bring to the table. “Stakeholders should know you and understand your added value and what you want to achieve with them in the project,” says van Luttikhuizen. Stakeholders need to smell what you’re cooking and like it, because the project has little chance of succeeding without their complete support.

“This may sound a bit trivial,” adds van Luttikhuizen, “but I’ve seen too many ivory-tower architects who just throw something out there. Without stakeholder support my architectural activities will not be followed and will just end up gathering dust.”

In order to earn that support, Brian Jimerson, a technical architect at Avantia in Cleveland, Ohio, sets up a project kickoff meeting with his internal customers. “I want to ensure that project goals are understood, establish communication channels, identify stakeholders and roles, and discuss the high-level project schedule,” Jimerson says. He also holds similar kickoff meetings with development teams to discuss project goals, milestones, and team structure.

Once you and your stakeholders are on the same page, it is time to impress everyone by waving your architecture wand. “In between the first steps and the project completion, a combination of creativity and engineering happens to identify and implement architectures that meet the goals,” says Stafford.

But there has to be some substance behind the magic. As the project progresses, it’s important to maintain your relationship with stakeholders by demonstrating your progress. “I try to deliver something useful as early as possible in the project,” says van Luttikhuizen.

“Depending on the type of architecture assignment—whether my role is software architect, solution architect, or enterprise architect—this can be a quick advice document, a working piece of software, or a guideline to help stakeholders.” These project milestones are important not just as progress indicators but also as proof of the value of architecture.

In the end, software architects are really only as good as their relationships with stakeholders. “Let’s face it—the critical thing for an architect’s career is to build a good reputation,” says Shepherd. Good reputations don’t spring from dysfunctional relationships with stakeholders.

If you want to earn your stripes as a software architect, you can’t relate to stakeholders by flinging furniture at them across the conference room. You need to understand what they want. They need to understand what you can deliver. Bring those two elements together through clear communication and everybody wins.

iOS: Download iOS 4.3.4 for iPhone, iPad | Direct Download Link

Apple just released iOS 4.3.4 software update  for iPhone 4, iPhone 3GS, iPod touch 4G, iPod touch 3G, iPad 2 and iPad. This new update does not add new features, it just patches the exploit in the easy to use JailbreakMe 3.0 software.

If you are already jailbroken on iOS 4.3.3 then you can simply install PDF Patcher 2 to keep your self safe from the PDF exploit. If you don’t jailbreak your hardware then you can go ahead and upgrade your device to iOS 4.3.4.

Download iOS 4.3.4 Links

§ iOS 4.3.4 download (iPad)

§ iOS 4.3.4 download (iPad 2) (WIFI)

§ iOS 4.3.4 download (iPad 2) (GSM) 

§ iOS 4.3.4 download (iPhone 4) (GSM)

§ iOS 4.3.4 download(iPhone 3GS)

§ iOS 4.3.4 download (iPod touch 4th generation)

§ iOS 4.3.4 download (iPod touch 3rd generation)

iOS 4.3.4 Jailbreak Information

The JailbreakMe 3.0 exploit will no longer work on iOS 4.3.4. There is no reason to update to iOS 4.3.4 as it adds no new features, and jailbroken users can easily patch the exploit by installing the PDF Patcher 2 application from Cydia. If you want to keep your jailbreak then don’t update to iOS 4.3.4.

App. Server: WebSphere Application Server V8 is another JEE6 is released

WebSphere V8.0 is released. WebSphere comes with full Java EE 6 support.

Jailbreak: TinyUmbrella Updated With Support for iOS 5b3

TinyUmbrella The  application that allows you to save SHSH your device from your Windows or Mac computer has just been updated to version 5.00.04 added support for IOS 5b3. Recall that, TinyUmbrella allows you to save the SHSH certificate so if you want to downgrade to an older firmware than the one installed and not signed by Apple, which would otherwise be impossible.

We highly advise you to save your SHSH so that can be used for future jailbreaks or downgrades, you can download  TinyUmbrella from following links.

You can download it here:

• Windows
• Mac

Flex: Flex and Java differences: Getters and setters

In Java it has become a standard practice to use a getter and setter notation to provide a consistent interface to an object’s properties. There is a reason why we don’t do the following in Java:

public String fullName;

The code above essentially creates an interface (or contract) between the class and the implementors of this class that does not allow us to change the underlying implementation of what gets returned when thefullName property is accessed on an instance of the class.

So if someone has Java code that accesses thefullName property:

blah = obj.fullName;

Or sets the fullName property:

obj.fullName = "blah";

Then in Java there is no way to change the behavior of getting or setting the fullName property.

If the author of the class wanted to change the underlying behavior of the getting or setting they would have to change how the implementors of the class interact with the class.

That is obviously not ideal so in Java we typically hide properties with get and set functions.

The Java language doesn’t yet have Java properties so we use methods to hide the implementation. So our Java class instead would be:

private String fullName;  public String getFullName() { return fullName; }  public void setFullName(String fullName) {this.fullName = fullName; }

This allows the class author to change the behavior of getting and setting the fullName property without changing the external interface.

In Flex it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var fullName:String;

If the internal implementation of getting or setting the fullName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _fullName:String;  public function get fullName():String {return _fullName; }  public function set fullName(_fullName:String):void {this._fullName = _fullName; }

To the class implementor the property fullName could still be get and set through the normal notations:

// getters blah = obj.fullName; blah = obj['fullName']; // setters obj.fullName = "blah"; obj['fullName'] = "blah";

Getting or setting the property would call the getter and setter functions instead of accessing the property directly.

This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes. This also allows a class to dispatch events when properties change (this is how Data Binding works internally in Flex).

I see a lot of Java developers who are wary of public properties on ActionScript classes.

Don’t be! ActionScript supports real properties so you shouldn’t ever need property getters and setters unless you are doing something out of the ordinary.

And you can switch to getters and setters without changing the interface to the object.