1. Can you name a number of non-functional (or quality) requirements?
Anything that is not a direct requirement by the buyer.
For instance, a buyer wants a software that periodically uploads an xml file to an FTP from a local directory. A functional requirement here is that system shall display a user interface that lists the files that have been transferred with date/time stamps and other information.
But "how frequent" the software should upload the file, is non functional requirement.
Similarly, the audit log modules that you write, and that “well known” archival windows service is a part of non functional requirement.
The file to interact with the software and configure; that is, provide the folder path/location and xml files with valid format.
Other non functional requirements, but not limited to, are Usability, that is user interactions with a system. How many times your customer will need to train the user? How complex is your user interface? What are you doing about drop down lists with more than 500+ items in it? Do you really expect your user to scroll down to 270th item using the mouse? (0;
Think about it.
What do you do? Provide the drop down list – as is? Provide a popup to find and select from? Or just provide a text box with “Find” button? Obviously, there the answer varies from situation to situation; But remember, anything that is interactive, intuitive for the user – is the best way to keep your user happy.
How about Security? Remember the SSO’s you have been integrating in all your web apps? Security is another non functional requirement.
Performance (response time?), reliability (this may boil down to the service level agreements/support – MTTR, MTBF, etc), maintainability (life cycle costing), efficiency (memory consumption, leakages?), are a few such examples of non functional requirements.
2. What is your advice when a customer wants high performance, high usability and high security?
Beware! The question is a fully loaded. I’ll KISS it according to the knowledge that I have (0:
High performance: is a broad term.
High performance computing, high performance storage system, high performance chassis (read: hardware specs); depending upon what exactly a buyer wants, your suggestion could be around the lines of: clustering, load balancing, mirroring, replication, fail over, segmentation; implementing RAID levels (for instance level 5 – being highest), SAM hardware, in-memory databases, etc.
If talking about high performance programming technology, go for using C++; this provides close to real time processing.
This means, ease of use. Allow user to use their intuition about how software will work or react to a user action.
Hire experienced user experience designers and have them research and come up with the best UI’s ever. What are you going to use most of the screen to display main content? How will you display menus and sidebars? Should they take up less space than the main content? How about when the screen goes to 800x600 from 1024 x 768? How your application will react to a range of internet browsers? Etc...
Conduct closely interacted rad/jad sessions with the customer; using iterative releases; fix font, color schemes, menus, bread-crumbs, action buttons, long lists, etc. Save your users from being POLArized.
Note that, the usability aspect is not only for software – it applies everywhere. Thinking about a mobile phone that has no button and you don’t know how to turn in on. Or a school bag that is a zipper inside out.
Depends upon the scenario and specific security requirements; if its non-repudiation security can be provided using SSL/transport level security, Client Certificates, PKI, TDES.
Use a combination of cryptographic techniques, for instance, symmetric, asymmetric, and hashing algorithms – wherever whichever is applicable.
Provide a solution of infrastructure that includes demilitarized zone (DMZ), encrypted transportation of data, fire walls, secure gateways, etc.
If from coding perspective, obfuscate your code; for instance .NET is almost an open source; so you will need to obfuscate your code in order to make it less prone to hack. Or use low level coding to keep the code to low level.
Use a centralized security mechanism, for instance providing SSO for centralized authentication; encrypted data sources, etc.
3. Can you name a number of different techniques for specifying requirements? What works best in which case?
Brainstorming, Focus Groups, Interface Analysis, Interview, Prototyping, Requirements Workshop, Reverse Engineering, Survey, etc.
4. What is a requirement tracing? What is backward tracing vs. forward tracing?
5. Which tools do you like to use for keeping track of requirements?
There could be several ways to keep track of requirements. Make a software requirements specifications document to list all of the requirements and description.
Prepare an excel sheet the list down the requirement, type, priority, dependency, etc.
Matt Light, Research VP, Gartner says:
“Requirements management can be simplified if initial requirements definitions are captured in a database-based tool to enable collaborative review... traceability and versioning/change control”.
Whatever you choose to maintain the list of the requirements, don’t forget the add that in your version control system.
I love Subversion(+ TortoiseSvn + AnkhSvn )
Cvs is ok.
Git is absolute.
6. How do you treat changing requirements? Are they good or bad? Why?
Change denotes life. No change means – stagnant or dead. Therefore change is an essential part of “life” and of course software industry.
Good or bad? Depends upon the sort of change.
A change in decision by buyer to shut down the project may not be a good change for the seller. A change to add three more buildings in a residential complex may be a good change for the seller.
How about the change, when a project, half way through using Oracle WebCenter as a base technology is decided to move to Microsoft Office SharePoint Server 2010?
Generally there is an Issue Control List(usually a Microsoft Excel Sheet?) also called Customer Issues and Changes List (CICL), containing date/time, request issuer, type of change(change request, bug, fix, etc), priority, description, remarks, and the status of the issue.
7. How do you search and find requirements? What are possible sources?
User, customer, developer, manager, sponsor, functional manager, business, technology departments, etc.
Note that even those shall be called stakeholders, who would “not” benefit from the project. How so? Because they “can” influence the management induce/reduce the scope of work or kill the project completely. For instance, you plan to install a payroll system in a bank; the bank personnel has been working in the administration departments for years (lets say 20+ years); and they “think” that after the installation of an electronic solution, company might decide to lay them off and keep only two or three employees. So, they might try any or all of the actions to shut this project down. In this case, these department personnel are one of the key stake holders to keep an eye on.
Possible sources of finding requirements, besides stakeholders are, company’s historical records that may contain the experiences of similar projects, market research, etc.
8. How do you prioritize requirements? Do you know different techniques?
Requirement prioritization is a process of formalizing and shifting focus on specific requirements. This includes gaining customer buy-in on prioritized requirements.
Agile development methodologies takes into account the requirement prioritization; you prioritize, select the requirements that you want to rollout for this iteration, validate and release the your software.
You will have to define some scale of prioritization based upon customer feedback. For instance, a customer may say that they want certain functionality first, and then they can come back on the user interface afterwards.
Here is a nice to read article, in case if you want to dig further.
Classical (stakeholders do the prioritization), Exhaustive (all areas including minor ones), and Value Based (prioritization based upon ROI) are a few prioritization techniques.
9. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
A simple responsibility assignment matrix can help. A list that contains and rest of the columns may contain the role name. For instance:
Role A: Project Sponsor
Role B: Project Manager
Role C: Business Analyst
Role D: System Analyst
Role E: Technical Architect
Role F: Programmer
Role N: Whatever that needs to be here
10. What do you do with requirements that are incomplete or incomprehensible?
This is a fairly subjective topic to be covered in a “definition”.
Generally, with incomplete or incomprehensible requirements, rolling-wave planning project management technique can be used; which emphasizes on focusing on small areas of requirement until further scope of requirement gets clearer.
Use requirements gathering techniques to gather as much information as possible.
But in cases where requirement is “incomplete or incomprehensible”, use Assumptions. Yep! Do not stop the work, make assumptions, let customers know about the assumptions you made in black and white, and move forward. In this case, Agile methodology will help.
STEP 1: Add/refine requirements + Assumptions
STEP 2: Build
STEP 3: Verify
STEP 4: Release/rollout
STEP 5: Iterate (Goto step 3)
STEP 6: Increment (Goto step 1)
I have found this small article to be very interesting and useful, especially if you do design the requirements or functional specifications documents.